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I.  INTRODUCTION 


A.  PURPOSE. 

This  thesis  defines  the  satellite  discipline  and  protocols  for  the  second  generation  of 
the  Officer  in  Tactical  Command  Information  Exchange  Subsystem  (OTCIXS II).  This 
document  provides  the  detailed  information  necessary  for  the  implementation  of  the 
OTCIXS  n  communications  protocol.  It  could  be  used  to  define  and  develop  the 
OTCIXS  II  satellite  link  software. 

The  OTCIXS  II  network  protocol  shall  consist  of  distinct  protocol  layers:  Physical, 
Data  Link,  and  Network  layers.  The  function  supported  by  each  of  these  layers  are: 

1 .  Physical  layer  -  The  Physical  layer  controls  interaction  of  OTCIXS  II  equipment 
suites  at  the  hardware  level. 

2.  Data  Link  layer  -  The  Data  Link  layer  ensures  an  error-free  transfer  of  information 
between  OTCIXS  II  subscribers. 

3.  Network  layer  -  The  Network  layer  controls  the  allocation  of  the  network 
resources  among  the  OTCIXS  II  subscribers  and  provides  the  vehicle  for  transporting 
OTCIXS  II  subscriber  to  subscriber  transactions. 

A  fourth  layer,  the  Transport  layer,  provides  the  actual  subscriber  to  subscriber  transaction 
service;  that  is,  the  transfer  of  formatted  computer-to-computer  data  and  teletype 
messages.  This  layer  is  beyond  the  scope  of  this  thesis.  A  description  of  this  transfer  layer 
protocol  is  defined  in  the  Tactical  Data  Information  Exchange  Subsystem  (TADIXS) 
Interface  Design  Specification,  Volume  I. 

B.  FUNCTIONAL  SUMMARY  OF  THE  OTCIXS  H. 

OTCIXS  II  will  support  inter  and  intra  battle  group  Tactical  communications. 
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including  delivery  of  Over-the-Horizon  Targeting  (OTH-T)  information.  OTCIXS  II  will 
support  ship-ship,  shore-ship,  and  ship-shore  tactical  data  exchange  between  user  systems 
as  described  in  the  following  subparagraphs. 

1.  Communications  Link. 

OTCIXS  II  operations  are  transparent  to  the  use  of  either  Fleet  Satellite 
(FLTSAT)  or  Leased  Satellite  (LEASAT)  satellites.  When  functioning  in  Demand 
Assigned  Multiple  Access  (DAMA)  mode,  OTCIXS  II  operates  in  a  half-duplex  manner  at 
a  data  rate  of  1200  or  2400  bits  per  second  (bps)  in  a  permanently  assigned  timeslot  of  an 
ultrahigh  frequency  (UHF)  DAMA  channel  to  support  subscriber  communications.  When 
functioning  in  Non-DAMA  mode,  OTCIXS  II  operates  in  a  half-duplex  manner  at  a  data 
rate  of 2400  or  4800  bps  using  a  dedicated  UHF  channel.  In  either  mode,  the 
communications  link  implemented  by  OTCIXS  II  is  referred  to  as  an  OTCIXS  II  radio 
frequency  (rf)  network.  In  the  coverage  area  of  an  individual  satellite  multiple  OTCIXS  II 
rf  networks  may  be  operated  independently. 

a.  Intranetwork  Communications. 

Intranetwork  communications  involve  the  exchange  of  messages  between 
user  systems  that  subscribe  to  a  common  OTCIXS  II  rf  network.  OTCIXS  II  will  directly 
supports  intranetwork  communications  for  the  user  system  Tactical  Data  Processors 
(TDPs)  shown  in  Table  1-1.  OTCIXS  II  intranetwork  connectivities  are  illustrated  in 
Figure  1-1. 

b.  Internetwork  Communications. 

Internetwork  communications  involve  the  exchange  of  messages  between  a 
user  system  that  subscribes  to  an  OTCIXS  II  rf  network  and  a  user  system: 
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1.  Ashore 


2.  That  subscribes  to  a  different  OTCIXS II  rf  network 

3.  That  subscribes  to  a  TADIXS  or  first  generation  OTCIXS  rf  network. 
Table  1-1.  OTCIXS  n  TDPs  Communicating  Intranetwork 


OTCIXS  n  USER  SYSTEM  TDP 

LOCATION 

Tomahawk  Weapons  Control  System  (TWCS) 

Surface  Ship 

Naval  Communications  Telecommunications  Stations  (NCTS) 

Shore/Surface  Ship 

Naval  Communications  Telecommunications  Station  (NCTAMS) 

Shore 

Global  Command  &  Control  System  -  Maritime  (GCCS-M) 

Surface  Ship 

Shore 

Joint  Operational  Tactical  System  (JOTS) 

Surface  Ship  /  Shore 

OTCIXS  II  will  operate  in  conjunction  with  TADIXS- A  to  support  the  internetwork 
communications  requirements  of  the  user  system  TDPs  shown  in  Table  1-2.  OTCIXS  II 
internetwork  connectivity  is  illustrated  in  Figure  1-2.  Internetworking  capabilities 
provided  by  TADIXS  Gateway  Facilities  (TGFs),  AN/USQ-64(V)9,  implement  the 
worldwide  connectivity  illustrated  in  Figure  1-3.  TGFs  are  located  at  Naval  Computer 
and  Telecommunications  Area  Master  Stations  (NCTAMS)  at  Norfolk,  Virginia 
(NCTAMS  LANT),  Wahiawa,  Hawaii  (NCTAMS  EASTPAC),  Finegayan,  Guam 
(NCTAMS  WESTPAC),  andBagnoli,  Italy  (NCTAMS  MED),  and  at  Naval  Computer 
Telecommunications  Station  (NCTS)  Stockton,  California. 

2.  OTCIXS  II  Subscriber  Equipment  Suites. 

Three  OTCIXS  II  subscriber  equipment  suites  need  be  implemented:  surface  ship. 
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submarine,  and  shore.  These  equipment  suites  are  described  in  the  following 
subparagraphs. 

Table  1-2.  TADIXS  A/OTCIXS  n  TDPs  Communicating  Internetwork 


TADIXS-A  USER  SYSTEM  TDP 

LOCATION 

Naval  Communications  Telecommunications  Station 

(NCTAMS) 

Shore 

Ocean  Surveillance  Information  System  (OSIS) 

Shore 

Mission  Data  Distribution  System  (MDDS) 

Shore 

a.  Surface  Ship. 

The  surface  ship  OTCIXS II  configuration  can  function  as  the  Network 


Control  Station  (NCS)  or  a  subscriber  unit  of  an  OTCIXS  II  rf  network  (either  DAMA  or 
non-DAMA  mode)  and  supports  message  exchange  for  the  TWCS,  FDDS,  and  teletypes. 
Figure  1-4  illustrates  the  surface  ship  configuration.  In  the  surface  ship  configuration,  the 


Figure  1-1.  OTCIXS  II  Intranetwork  Connectivity 


OTCIXS II  subscriber  equipment  suite  consists  of  the  following  components: 


(1).  ON-143(V)6/USQ  and/or  ON-143(V)14/USQ  Interconnecting 
Groups,  including  Control  Indicator  (Cl),  a  human  control  interface  (HCI)  device,  and 
the  necessary  software  to  enable  it  to  function  as  an  OTCIXS  II  Link  Controller.  The 
ON-143(V)6  of  (V)14  hosting  the  OTCIXS  II  Link  Controller  also  supports  access  to  a 


TADIXS-A  rf  network.  The  TADIXS-A  link  protocols  are  capabilities  outside  the  scope 
of  this  thesis. 


mmwm  mm 

1 

OSIS 

Mnns 

STT 

JOTS 

ADJACENT  TFG  ADJACENT  TFG 


Figure  1-2.  OTCIXS  II  Internetwork  Connectivity 
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Figure  1-3.  OTCEXS  II  Worldwide  Connectivity  by  TADIXS 

(2) .  KG-84A  Cryptographic  Unit. 

(3) .  AN/UGC-136BX  or  AN/UGC-77  Teletype 
b.  Submarine. 

The  submarine  OTCIXS II  configuration  functions  as  a  subscriber  unit  of  a 
Non-DAMA  OTCIXS  II  rf  network.  The  submarine  OTCIXS  II  configuration  supports 
message  exchange  for  the  CCS  MK-1  /  MK-2  and  teletype.  Figure  1-5  illustrates  the 
submarine  configuration.  In  the  submarine  configuration,  the  OTCIXS  II  subscriber 
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equipment  suite  consists  of  the  following  components: 

(1) .  ON-143(V)6/USQ  or  ON-143(V)14/USQ  Interconnecting 
Group,  including  Cl,  with  the  necessary  software  to  enable  it  to  function  as  an  OTCIXS II 
Link  Controller.  The  ON-143(V)6  hosting  the  OTCIXS  II  Link  Controller  also  supports 
access  to  a  TADIXS-A  or  Submarine  Satellite  Information  Exchange  Subsystem  (SSIXS) 
rf  network.  SSIXS  capabilities  are,  however,  outside  the  scope  of  this  thesis. 

(2) .  KG-84A  Cryptographic  Unit. 

(3) .  AN/UGC-136AX  or  AN/UGC-77  Teletype. 
c.  Shore. 

The  shore  OTCIXS  II  configuration  functions  as  other  NCS  or  a 
subscriber  unit  of  the  OTCIXS  II DAMA  or  Non-DAMA  rf  network.  It  functions  under 
the  control  of  the  TADIXS  Gateway  Processor  (TGP)  and  supports  the  relay  of  subscriber 
messages  between  different  rf  networks  or  between  user  systems  ashore  and  subscribers  to 
the  OTCIXS  II  rf  network  it  accesses.  Ashore  TDPs  supported  by  the  OTCIXS  II  Link 
Controller  are  the  TDDS,  Shore  Targeting  Terminal  (STT),  Joint  Operational  Tactical 
System  (JOTS),  Global  Command  and  Control  System  -  Maritime  (GCCS-M),  Ocean 
Surveillance  Information  System  (OSIS),  OSIS  Baseline  Upgrade  (OBU),  and  MDDS. 
Figure  1-6  illustrates  the  shore  configuration. 

In  the  shore  configuration,  the  OTCIXS  II  subscriber  equipment  suite  consists  of  the 
following  components: 

(1).  ON-143(V)6/USQ  Interconnecting  Group,  including  Cl,  with 
the  necessary  software  also  functions  as  the  shore  OTCIXS  II  Link  Controller. 
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OTCIXS I  communications  is  via  single  WSC-3  (non-DAMA) 

TADDCS  A  Communications  is  via  WSC-5  /  TD-1271/BU  (DAMA  unit) 
OTCIXS  D  can  be  via  WSC-3/5  and/or  TD-1271-BU  DAMA  unit 
(DAMA  &  non-DAMA  mode) 


Figure  1-4.  Surface  Ship  Configuration  with  OTCIXS  II 
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Figure  1-5.  Submarine  Configuration  with  OTCIXS II 
(2).  KG-84A  Cryptographic  Unit. 

3.  Subscriber  Identification. 

Each  OTCIXS  II  subscriber  is  identified  by  a  unique  Subscriber  Identification 


(SID)  number  which  may  range  from  0001  to  9999.  The  OTCIXS  II  accommodates  the 
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following  address  types: 

a.  Discrete.  A  discrete  SID  is  the  unique  number  assigned  to  a  specific  surface 
ship,  submarine,  or  shore  facility. 

b.  Collective.  A  collective  SID  is  the  unique  number  assigned  to  a  group  of  fleet 
units  or  commands.  Provisions  exist  for  two  types  of  collective  addresses.  These  are: 

1.  Organizational.  Organizational  collectives  contain  specific  fleet 
platforms  or  shore  commands.  The  composition  of  an  organizational  collective  may 
change  with  time. 

2.  Regional.  Regional  collectives  are  associated  with  a  specific  satellite 
coverage  area  and  effectively  constitute  an "...  all  subscribers  in  a  geographic  region ..." 
address. 

a.  Subscriber  Data. 

The  OTCIXS II  facilitates  the  timely  exchange  of  subscriber  messages. 
The  OTCIXS  II  neither  depends  upon  nor  analyzes  the  information  content  of  such 
messages  but  employs  information  contained  in  specially  formatted  "header"  preambles 
which  are  attached  to  every  message  transferred  over  the  satellite  link.  To  support  the 
internetwork  routing  of  messages  by  TADIXS-A,  OTCIXS  II  messages  must  conform  to 
the  requirements  imposed  by  Volume  I  of  the  TADIXS  Interface  Design  Specification 
(IDS). 
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Figure  1-6.  OTCIXS II  Shore  Gateway  Configuration 
b.  Nonscheduled  and  Scheduled  Broadcasts. 

The  OTCIXS  n  includes  operating  features  needed  to  support  both 
Nonscheduled  and  Scheduled  broadcasts.  Nonscheduled  Broadcasts  occur  randomly  and 
are  independent  of  specific  preplanned  instants  in  real  time.  Nonscheduled  broadcasts 
may  be  executed  from  any  OTCIXS  II  configuration.  Scheduled  Broadcasts  occur  only  at 
preplanned  instants  in  real  time.  To  define  and  execute  a  scheduled  broadcast  from  a 


11 


surface  ship  configuration  the  OTCIXS II  Link  Controller  receives  all  information 
required  to  implement  that  broadcast  from  the  OTCIXS  II  operator  via  the  attached  Cl. 
This  information  includes  the  number  of  times  transmission  is  to  occur  and  the  times  in 
each  hour,  expressed  in  quarter  hours  and  minutes  past  the  quarter  hour,  at  which  each 
transmission  is  to  commence.  To  define  and  execute  a  scheduled  broadcast  from  a  shore 
configuration,  the  OTCIXS  II  Link  Controller  receives  all  information  required  to 
implement  that  broadcast  from  its  interfaced  TGP.  Scheduled  broadcasts  cannot  be 
defined  or  executed  from  a  submarine  configuration. 

4.  Message  Identification. 

Each  subscriber  to  the  OTCIXS  H  rf  network  assigns  a  16-bit  identifier  to  each 
message  it  transmits  on  that  network.  This  identifier  and  the  transmitting  subscriber's  SID 
provide  unique  message  identification  for  message  accountability. 

a.  Message  Length. 

OTCIXS  II  accommodates  messages  up  to  10,103  bytes  in  length. 
Messages  exceeding  the  maximum  length  must  be  divided  by  the  originator,  into  multiple 
parts,  each  part  not  to  exceed  the  maximum  length.  OTCIXS  II  treats  each  part  of  a 
multi-part  message  as  a  separate  message.  The  user  computer  system  is  responsible  for 
segmenting,  reassembling,  and  sequencing  the  parts  of  a  multi-part  message. 

b.  Message  Precedence. 

The  OTCIXS  II  recognizes  Flash  and  Immediate  precedence  levels.  Flash 
precedence  messages  always  receive  transmission  priority  over  immediate  precedence 
messages.  Flash  precedence  messages  always  receive  transmission  priority  over  scheduled 
broadcast  messages.  Scheduled  broadcast  messages  receive  transmission  priority  over 
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nonscheduled  Immediate  precedence  messages, 
c.  Network  Control 

A  subscriber  designated  as  the  Net  Control  Station  (NCS)  coordinates  the 
use  of  the  OTCIXS II  network.  All  surface  ship  and  shore  sites  will  be  capable  of 
assuming  the  NCS  function.  The  NCS  receives,  queues,  and  acknowledges  receipt  of 
subscriber  access  requests.  Queued  requests  will  be  serviced  in  accordance  with  a 
first-come,  first-served  by  precedence  network  server  discipline.  The  NCS  will  assign 
service  and  assign  transmission  times  to  all  Flash  requests,  then  scheduled  Immediate 
requests,  and  finally  nonscheduled  Immediate  requests.  Transmission  of  subscriber  data 
occurs  only  when  authorized  by  the  NCS.  Once  a  subscriber  has  been  authorized  by  the 
NCS  to  transmit  its  message,  the  subscriber  will  commence  message  transmission.  Once 
message  transmission  has  commenced,  the  transmission  will  not  be  preempted  by  other 
message  transmissions  regardless  of  the  precedence  of  the  messages  involved. 

C.  CONTENT  DESCRIPTION. 

The  remainder  of  this  document  consists  of  the  following  sections  and  appendixes: 

1 .  Section  EL,  Applicable  Documents,  provides  a  list  of  documents  applicable  to 
the  preparation  of  this  document. 

2.  Section  III,  Interface  Summary  Cross-Index,  provides  a  cross-index  of  signals 
transferred  between  OTCIXS  II  subscribers. 

3.  Section  IV,  Signal  Definitions  List,  defines  the  usage  and  effect  of  each  signal 
transferred  between  OTCIXS  II  subscribers. 

4.  Section  V,  Narrative  Signal  Flow  Table,  describes  each  interface  signal  as  well 
as  the  interactions  and  interrelationships  among  the  signals. 
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5.  Section  VI,  Communication  Controls  and  Conventions,  defines  and  describes 
the  communication  control  responsibilities  and  conventions  for  each  of  the  OTCEXS  n 
subscribers. 

6.  Section  VH,  Data  Unit  Descriptions,  provides  a  detailed  description  of  the  data 
unit  formats.  This  section  will  incorporate  material  specified  by  DI-E-2 135.  This 
interface  type  lends  itself  to  the  combined  section  and  a  clearer  representation  of  the 
material  is  accomplished. 

7.  Appendix  A,  List  of  Acronyms  and  Abbreviations,  provides  a  list  of  acronyms 
and  their  respective  definitions. 

8.  Appendix  B,  Cyclic  Redundancy  Check  Generation,  lists  and  describes  the 
algorithm  bang  used  to  generate  the  Cyclic  Redundancy  Check. 

9.  Appendix  C,  OTCIXS II  Simulation  Results. 

10.  Appendix  D,  OTCIXS  II  Model  Simulation  Setup  File  Format. 

11.  Appendix  E,  Setup  File  Standard  Values. 
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II.  INTERFACE  SUMMARY  CROSS-INDEX 


A.  GENERAL 

This  section  provides  a  tabular  index  to  sections  IV  (Signal  Definition  List),  V 
(Narrative  Signal  Flow  Table),  and  VII  (Data  Unit  Descriptions)  for  each  signal  passed 
between  members  of  an  OTCIXS II  network.  It  also  lists  and  provides  a  cross-reference 
index  (Table  2-1)  to  sections  IV,  V,  and  VH  for  the  Physical  layer  signals  employed  by  the 
OTCIXS  II  Link  Controllers  interfacing  with: 

1.  KG-84 A  cryptographic  device 

2.  TD-1271B/UDAMA  multiplexer 

3.  AN/WSC-3/5  transceiver. 

B.  SIGNAL  SUMMARY  CROSS-INDEX  -  NET  CONTROL  STATION  TO 
SUBSCRIBER 

Table  2-2  list  the  signals  passed  from  the  OTCIXS  II  Net  Control  Station  (NCS) 
to  the  OTCIXS  II  subscribers  and  provides  a  cross-reference  index  to  sections  IV,  V,  and 
VH.  , 

C.  SIGNAL  SUMMARY  CROSS-INDEX  -  SUBSCRIBER  TO  NET  CONTROL 
STATION. 

Table  2-3  list  the  signals  passed  from  the  OTCIXS  II  subscribers  to  the  OTCIXS 
II  NCS  and  provides  a  cross-reference  index  to  sections  IV,  V,  and  VH. 

D.  SIGNAL  SUMMARY  CROSS-INDEX  -  SUBSCRIBER  TO  SUBSCRIBER 
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Table  2-4  list  the  signals  passed  between  OTCIXS II  subscribers  and  provides  a 


cross-reference  index  to  sections  V,  V,  and  VII. 

Table  2-1.  Physical  Layer  Signal  Cross-Index 


SIGNAL  NAME 

PAGE  NUMBER  INDEX  TO 

SIGNAL 

NARRATIVE 

DATA  UNIT/ 

DEFINITION 

SIGNAL 

MESSAGE 

LIST 

FLOW  TABLE 

DESCRIPTION 

1.  Channel  Busv 

24 

45 

2.  Crvpto  Alarm  Indicate 

24 

49 

3.  Crvoto  Alarm  Reset 

24 

49 

4.  Crvpto  PREP 

24 

42  &  46 

„ 

5.  External  Transmit  Reauest 

24 

46 

_  - 

6.  Kevline 

25 

42 

_ 

7.  Receive  Data 

25 

45  &  48 

„ 

8.  Receive  Data  Black 

25 

45  &  48 

9.  Receive  Data  Red 

25 

45  &  48 

_ 

10.  Sianal  Acouired  ISIGACOl 

25 

48 

__ 

25 

46 

12.  Transmit  Data 

26 

44  &  47 

_ 

13.  Transmit  Data  Black 

26  1 

44  &  47 

_ 

14.  Transmit  Data  Red 

26 

44  &  47 

15.  Black  Transmit  Clock 

26 

16.  Black  Receive  Clock 

26 

| 

17.  Black  Receive/Transmit  Clock 

27 

I  __ 

18.  Red  Gated  Clock 

27 

— 

— 
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Table  2-2.  NCS  to  Subscriber  Signal  Cross-Index 


PAGE  NUMBER  INDEX  TO 


1 .  Data  Link  Layer  Packet 

a.  Count 

b.  Cyclic  Redundant  Check  (CRC) 

c.  End 

d.  Information _ 

2.  Net  Control  Block  (NCB) 

Transmission  Unit  (TU) 

a.  Component  Identification  (CID) 

b.  Copy 

c.  Flash  Slots 

d.  Granted  Subscriber  ID  (GSID) 

e.  Hits 

f.  Hours 

g.  Immediate  Slots 

h.  Minutes 

i.  Mode 

j.  Net  Control  Station  (NCS)  Link 
Access  Queue 

k.  Net  Control  Station  (NCS)  Link 
Access  Queue  Size 

l.  Net  Control  Station  (NCS)  SID 

m.  RATS  Type 

n.  Scheduled  Broadcast  Status  (SB 
STATUS) 

o.  Seconds 

p.  STU1  Acknowledge 

q.  STU2  Acknowledge 

r.  STU3  Acknowledge 

s.  Time  Checksum 

t.  Transmit  Count  (XMIT  CT) 

u.  Window  Size 


SIGNAL 

DEFINITION 

LIST 


27 


NARRATIVE 
SIGNAL  FLOW 
TABLE 


DATA  UNIT/ 
MESSAGE 
DESCRIPTION 


135 


Table  2-2.  NCS  to  Subscriber  Signal  Cross-Index  (cont.) 


SIGNAL  NAME 

PAGE  NUMBER  INDEX  TO 

SIGNAL 

DEFINITION 

LIST 

NARRATIVE 
SIGNAL  FLOW 
TABLE 

DATA  UNIT/ 
MESSAGE 
DESCRIPTION 

3.  Network  Message 

31 

— 

134 

a.  Block  Check  Sequence  (BCS) 

b.  Broadcast  Sequence  Number  (BSN) 
a.  c.  Transport  Message 

4.  Subscriber  Transmission  Unit  (STU) 

32 

57 

128 

a.  Component  Identification  (CID) 

b.  Copy 

c.  Message  Pointer  Block 

d.  Mode 

e.  More 

f.  Network  Message 

g.  Precedence  (PREC) 

h.  Reservation  (RESV) 

i.  Subscriber  Identification  (SID) 

j.  Transmit  Count  (XMIT  CT) 

k.  Transmit  Minute 

i 
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Table  2-3 .  Subscriber  to  NCS  Signal  Cross-Index 


SIGNAL  NAME 

PAGE  NUMBER  INDEX  TO 

SIGNAL 

DEFINITION 

LIST 

NARRATIVE 
SIGNAL  FLOW 
TABLE 

DATA  UNIT/ 
MESSAGE 
DESCRIPTION 

1 .  Data  Link  Layer  Packet 

a.  Count 

b.  Cyclic  Redundancy  Check  (CRC) 

c.  End 

d.  Information 

27 

135 

2.  Network  Message 

a.  Block  Check  Sequence  (BCS) 

b.  Broadcast  Sequence  Number  (BSN) 

c.  Transport  Message 

34 

134 

3.  Reservation  Request  TU  (RRTU) 

a.  Component  Identification  (CID) 

b.  Copy 

c.  Mode 

d.  Retry  Count 

e.  Subscriber  Identification  (SID) 

f.  Transmit  Count  (XMIT  CT) 

g.  Transmit  Minute 

34 

54 

125 

4.  Subscriber  Transmission  Unit  (STU) 

a.  Component  Identification  (CID) 

b.  Copy 

c.  Message  Pointer  Block 

d.  Mode 

e.  More 

f.  Network  Message 

g.  Precedence  (PREC) 

h.  Reservation  (RESV) 

i.  Subscriber  Identification  (SID) 

j.  Transmit  Count  (XMIT  CT) 

k.  Transmit  Minute 

35 

57 

128 
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Table  2-4.  Subscriber  to  Subscriber  Signal  Cross-Index 


SIGNAL  NAME 

PAGE  NUMBER  INDEX  TO 

SIGNAL 

DEFINITION 

LIST 

NARRATIVE 
SIGNAL  FLOW 
TABLE 

DATA  UNIT/ 
MESSAGE 
DESCRIPTION 

1 .  Data  Link  Layer  Packet 

27 

— 

135 

a.  Count 

b.  Cyclic  Redundancy  Check  (CRC) 

c.  End 

d.  Information 

2.  Network  Message 

37 

— 

134 

a.  Block  Check  Sequence  (BCS) 

b.  Broadcast  Sequence  Number  (BSN) 

c.  Transport  Messaee 

3.  Subscriber  Transmission  Unit  (STU) 

37 

57 

128 

a.  Component  Identification  (CID) 

b.  Copy 

c.  Message  Pointer  Block 

d.  Mode 

e.  More 

f.  Network  Message 

g.  Precedence  (PREC) 

h.  Reservation  (RESV) 

i.  Subscriber  Identification  (SID) 

j.  Transmit  Count  (XMIT  CT) 

k.  Transmit  Minute 

20 


III.  SIGNAL  DEFINITION  LIST 


A.  GENERAL 

This  section  defines  the  physical  interface  signals  used  by  the  OTCIXS II  Link 
Controller  to  control  and  monitor  the  KG-84A  cryptographic  unit,  TD-1271B/U  DAMA 
multiplexer,  and  AN/WSC-3/5  transceiver.  It  also  defines  the  signals  exchanged  between 
members  of  an  OTCIXS  II  network. 

1.  Protocol  Layers. 

The  interface  as  described  in  this  document  consists  of  several  protocol  layers: 

a.  Physical  Layer  -  The  Physical  Layer  are  the  signals  that  the  OTCIXS  II  software 
generates  to  control  the  OTCIXS  II  equipment  or  receives  to  monitor  the  OTCIXS  II 
equipment.  Signals  discussed  are  the  signals  between  the  ON-143(V)6  or  ON-143(V)14  (here 
after  referred  to  as  the  OTCIXS  II  Link  Controller)  and: 

1.  KG-84A  cryptographic  device. 

2.  TD-1271B/U  DAMA  multiplexer. 

3.  AN/WSC-3/5  transceiver. 

b.  Data  Link  Layer  -  The  Data  Link  Layer  comprises  the  signals  used  to  ensure  an 
error-free  transfer  of  information  between  OTCIXS  II  subscribers. 

c.  Network  Layer  -  The  Network  Layer  comprises  the  signals  to  control  the  allocation 
of  the  network  resources  among  the  OTCIXS  II  subscribers  and  the  vehicle  for  transporting 
OTCIXS  II  subscriber  to  subscriber  transactions. 

2.  General  Definitions. 

General  definitions  pertinent  to  the  discussion  of  this  interface  are: 
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a.  Broadcast  Sequence  Number  (BSN)  -  the  BSN  is  a  16-bit  quantity  assigned  to  a 
network  message  by  the  subscriber  that  originates  an  OTCIXS II  transmission.  BSNs  shall  be 
assigned  sequentially  so  that  missed  messages  can  be  detected  by  a  gap  in  the  BSNs  received 
from  a  subscriber. 

b.  Transmission  Unit  (TU)  -  the  TU  is  the  entity  that  is  transferred  over  the  OTCIXS 
II  network.  All  data  items,  network  control  and  messages,  shall  be  transmitted  over  the 
OTCIXS  II  network  in  TUs. 

c.  Net  Control  Station  (NCS)  -  an  OTCIXS  II  subscriber  that  controls  the  allocation 
of  transmission  time  among  the  OTCIXS  n  network  members. 

d.  Link  Access  Queue  (LAQ)  -  a  queue  maintained  by  the  NCS  that  identifies  each 
OTCIXS  II  subscriber  that  has  requested  network  transmission  time.  The  queue  shall  be 
ordered  first  in,  first  out  (FIF  O)  by  precedence. 

e.  Net  Cycle  -  an  OTCIXS  II  net  cycle  is  the  time  from  the  transmission  of  a  Net 
Control  Block  (NCB)  by  the  NCS  to  the  next  transmission  of  a  NCB  by  the  NCS.  There  are 
two  types  of  net  cycles:  Idle  and  Busy.  An  idle  cycle  is  a  net  cycle  where  no  subscriber 
transmissions  occur.  A  busy  cycle  is  a  net  cycle  where  a  subscriber  transmission  occurs.  Each 
net  cycle  consists  of  time  slots,  as  follows: 

1 .  Control  Time  Slot  (CTS)  -  provides  the  information  to  control  the  operation 
of  the  network.  NCBs  are  transmitted  in  the  CTS. 

2.  Random  Access  Time  Slot  (RATS)  -  provides  the  period  for  OTCIXS  II 
subscribers  to  request  transmission  time.  Reservation  Request  (RR)  TUs  (RRTUs),  containing 
subscriber  requests  for  net  time,  are  transmitted  in  the  RATS. 

3 .  Subscriber  Transmission  Time  Slot  (STTS)  -  provides  the  period  for 
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subscribers  to  transmit  network  messages.  Subscriber  TUs  (STUs),  containing  network 
messages,  are  transmitted  in  the  STTS. 

f.  Network  Message  -  the  entity  transferred  by  the  OTCIXS  H  protocol  including 
sequencing  to  provide  the  mechanism  for  the  detection  of  missed  messages  and  a  Block  Check 
Sequence  (BCS)  used  in  error  detection. 

g.  Request  Slot  (RS)  -  a  period  in  a  RATS  where  a  subscriber  is  permitted  to  request 
net  time  from  the  NCS.  There  are  two  types  of  request  slots:  Immediate  and  Flash. 

h.  Subscriber  Identification  (SID)  -  the  SID  uniquely  identifies  a  subscriber  in  the 
communication  networks  accessed  by  TADIXS  (which  includes  OTCIXS  IT). 

i. .  Transport  Message  -  the  subscriber-to-subscriber  information  entity,  that  is, 
formatted  computer-to-computer  data,  teletype,  and  system  control  messages. 

B.  PHYSICAL  LAYER  SIGNAL  DEFINITION  LIST 

Physical  Layer  interface  signals  employed  by  the  OTCIXS  II  Link  Controller  to  control 
and  monitor  the  KG-84A  cryptographic  unit,  TD-1271B/U  DAMA  multiplexer,  and  the 
ANAVSC-3/5  transceiver  are  defined  in  Table  3-1. 

C.  DATA  LINK  LAYER  SIGNAL  DEFINITION  LIST.  The  Data  Link  interface  signals 
employed  by  the  OTCIXS  II  Link  Controller  are  defined  in  Table  3-2. 

D.  NETWORK  LAYER  SIGNAL  DEFINITION  LIST.  The  Network  Layer  interface 
signals  employed  by  the  OTCIXS  II  Link  Controller  are  grouped  into  three  categories: 

a.  Net  Control  Station  (NCS)  to  Subscriber.  Signals  transferred  from  the  OTCIXS  II 
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NCS  to  OTCIXS II  subscribers  are  listed  and  defined  in  Table  3-3. 

b.  Subscriber  to  Net  Control  Station.  Signals  transferred  from  OTCIXS  II  subscribers 
to  the  OTCIXS  II  NCS  are  listed  and  defined  in  Table  3-4. 

c.  Subscriber  to  Subscriber.  Signals  transferred  between  OTCIXS  II  subscribers  are 
listed  and  defined  in  Table  3-5. 

Fields  containing  critical  data  items  in  these  data  units  are  triply  encoded.  Triply 
encoded  fields  consist  of  the  contents  of  the  field  itself  the  contents  of  the  field  in  the  one's 
complement  form,  and  the  contents  of  the  field  Exclusive  ORed  with  a  binary  pattern  of 
alternating  ones  and  zeros  commensurate  with  the  width  of  the  field.  A  match  of  at  least  two 
of  these  fields  will  validate  the  contents  of  the  field. 


Table  3- 1 .  Physical  Layer  Signal  Definition  List 


SIGNAL 

DEFINITION 

1.  Channel  Busy 

A  signal  from  fee  AN/WSC-3/5  to  fee  OTCIXS  II  Link  Controller 
to  indicate  that  a  signal  is  present.  It  is  received  on  Channel  A,  bit  4, 
of  fee  Parallel  Input/  Output  (PIO)  on  fee  Black  Dynamic  Adaptive 
Receiver/  Transmitter  (DART)  in  fee  OTCIXS  II  link  Controller. 

This  signal  is  used  onlv  in  Non-DAMA  mode  ooerations. 

2.  Crypto  Alarm  Indicate 

A  signal  from  fee  crypto  to  fee  OTCIXS  II  Link  Controller  to 
indicate  feat  it  is  in  fee  alarm  state.  It  is  received  on  channel  B,  bit  2, 
of  fee  PIO  on  fee  Crypto  DART  in  fee  OTCIXS  H  Link  Controller. 
This  signal  is  sort  by  fee  KG-84A  as  Red  Alarm  Indicate  (RED-AI). 

3.  Crypto  Alarm  Reset 

A  signal  from  fee  OTCIXS  II  Link  Controller  to  fee  crypto  to  clear 
fee  alarm  state.  It  is  salt  on  channel  B,  bit  6,  offee  PIO  on  fee 

Crypto  DART  in  fee  OTCIXS  II  Link  Controller.  This  signal  is 
received  bv  fee  KG-84A  as  Remote  Standbv  Red  fRP-STBYR) 

4.  Crypto  PREP 

A  signal  from  fee  OTCIXS  II  Link  Controller  to  fee  crypto  to  put  fee 
crypto  into  fee  transmit  mode  and  resynchronize  it.  It  is  sent  on 
channel  B,  bit  7,  offee  PIO  on  fee  Crypto  DART  in  fee  OTCIXS  II 
Link  Controller.  This  signal  is  received  by  fee  KG-84A  as 
Synchronize  Command  Transmit  ISYNC-CMD-TX1 

5.  External  Transmit 
Request 

Signal  sent  by  fee  OTCIXS  II  Link  Controller  to  fee  TD-1271B/U 
multiplexer  to  transmit  a  TTJ  over  fee  OTCIXS  II  network.  It  is  salt 
on  channel  B,  bit  6  and  7,  offee  PIO  on  Black  Dart  in  fee  OTCIXS 

II  Link  Controller.  This  signal  is  used  only  in  DAMA  mode 
operations. 
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Table  3-1 .  Physical  Layer  Signal  Definition  List  (cont.) 


SIGNAL 

DEFINITION 

6.  Keyline 

Signal  sent  by  the  OTCIXS  n  Link  Controller  to  the 
ANAVSC-3/5  transceiver  to  transmit  a  TU  over  the  OTCIXS 

II  network.  It  is  sent  on  channel  B,  bit  6  and  7 ,  of  the  PIO  on 
the  Black  DART  in  the  OTCIXS  II  Link  Controller.  This 
signal  is  used  only  in  Non-DAMA  mode  operations.  (In 
DAMA  mode  operations,  the  TD-1271B/U  performs 
transceiver  kev  functions! 

7.  Receive  Data 

Serial  data  received  by  the  black  side  of  the  OTCIXS  II  Link 
Controller  from  the  ANAVSC-3/5  (Non-DAMA  mode 
operations)  or  TD-1271B/U  (DAMA  mode  operations).  The 
data  is  clocked  by  an  internally  generated  clock  that  is 
synchronized  to  the  external  clock  generated  by  the  sending 
device. 

8.  Receive  Data  Black 

Serial  data  sent  to  the  crypto  from  the  black  side  of  the 
OTCIXS  II  Link  Controller.  Data  is  clocked  by  an  internally 
generated  clock  that  is  synchronized  to  the  external  clock 
generated  by  the  An/WSC-3/5  transceiver  (Non-DAMA  mode 
operation)  or  by  the  TD-1271B/U  multiplexer  (DAMA  mode 
operations).  This  signal  is  received  by  the  KG-84A  as 

External  Receive  Cvohered  Text  (ERCTV 

9.  Receive  Data  Red 

Serial  data  received  from  the  crypto  by  the  red  side  of  the 
OTCIXS  II  Link  Controller.  Data  is  clocked  by  an  internally 
generated  clock  that  is  synchronized  to  the  external  clock 
generated  by  the  AN/WSC-3/5  transceiver  (Non-DAMA 
mode  operations  or  by  the  TD-1271B/U  multiplexer  (DAMA 
mode  operations).  This  signal  is  sent  by  the  KG-84A  as 
Receive  Digital  Plain  Text  (RX-DPT1. 

10.  Signal  Acquired 
(SIGACQ) 

A  signal  from  the  TD-1271B/U  multiplexer  to  the  OTCIXS  II 
Link  Controller  to  indicate  that  a  signal  is  present.  It  is 
received  on  channel  A,  bit  4  of  the  PIO  on  the  Black  DART  in 
the  OTCIXS  II  Link  Controller.  This  signal  is  used  only  in 
DAMA  mode  ooerations. 

11.  Slot  Time  Mark  Signal  received  by  the  OTCIXS II  Link  Controller  from  the 

(STM)  TD-1271B/U  to  provide  DAMA  timing.  It  is  received  on 

channel  B,  bit  4,  of  the  PIO  on  both  the  Crypto  and  Black 
DART  in  the  OTCIXS II  Link  Controller.  Signal  is  received 
every  1.38667  seconds  to  provide  synchronization  with  the 
DAMA  timeslot.  Signal  is  used  only  in  DAMA  mode 
operations. 
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Table  3-1 .  Physical  Layer  Signal  Definition  List  (cont.) 


SIGNAL 

DEFINITION 

12.  Transmit  Data 

Serial  data  sent  by  the  black  side  of  the  OTCIXS II  Link 
Controller  to  the  AN/WSC-3/5  (Non-DAMA  mode 
operations)  or  the  TD-1271B/U  (DAMA  mode  operations). 

Die  data  is  clocked  by  an  internally  generated  clock  that  is 
synchronized  to  the  external  clock  generated  by  the  receiving 
device. 

13.  Transmit  Data  Black 

Serial  data  received  by  the  black  side  of  the  OTCIXS  II  Link 
Controller  from  the  crypto.  The  data  is  clocked  by  an 
internally  generated  clock  that  is  synchronized  to  the  external 
clock  generated  by  the  AN/WSC-3/5  transceiver  (Non- 
DAMA  mode  operations)  or  by  the  TD-1271B/U  multiplexer 
(DAMA  mode  operations).  This  signal  is  sent  by  the  KG-84A 
as  External  Transmit  Cyphered  Text  (ETCT) 

14.  Transmit  Data  Red 

Serial  data  sent  by  the  red  side  of  the  OTCIXS  II  Link 

Controller  to  the  crypto.  The  data  is  clocked  by  an  internally 
generated  clock  that  is  synchronized  to  the  external  clock 
generated  by  the  AN/WSC-3/5  transceiver  (Non-DAMA 
mode  operations)  or  by  the  TD-1271B/U  multiplexer  (DAMA 
mode  operations).  This  signal  is  received  by  the  KG-84A  as 
Transmit  Digital  Plain  Text  (TX-DPTV 

15.  Black  Transmit  Clock 

This  signal  is  generated  by  the  AN/WSC-3  or  TD-1271B/U. 

It  provides  transmit  data  bit  interval  timing  information  to  the 
OTCIXS  II  Link  Contorller.  It  is  connected  to  connector  J1 
pin  #70.  The  signal  is  then  routed  through  the  Radio 

Interface  Board  (RIB)  to  the  Black  DART  board.  The  RIB 
card  allows  inversion  and  source  selection  of  the  transmit 
clock  signal.  During  a  transit  sequence,  the  Black  DART 
software  samples  the  transition  of  the  transmit  clock  on  PIO 
bit  B2.  It  then  phase-locks  the  CTC  0  timer  to  provide  a 
stable  Black  Transmit  Clock  to  the  KG-84A. 

16.  Black  Receive  Clock 

This  signal  is  generated  by  the  AN/WSC-3  or  TD-1271B/U. 

It  provides  receive  data  bit  interval  timing  information  to  the 
OTCIXS  II  Link  Controller.  It  is  connected  to  connector  J1 
pin  #  76.  The  signal  is  then  routed  through  RIB  to  the  Black 
DART  board.  The  RIB  card  allows  inversion  and  source 
selection  of  the  receive  clock  signal.  During  a  receive 
sequence,  the  Black  DART  software  samples  the  transition  of 
the  receive  clock  on  PIO  bit  B3 .  It  then  phase-locks  the  CTC 

0  timer  to  provide  a  stable  Black  Receive  Clock  to  the  KG- 
84A  device. 
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Table  3-1 .  Physical  Layer  Signal  Definition  List  (cont.) 

SIGNAL  _ _ DEFINITION _ _ 

17.  Black  This  signal  is  generated  by  the  CTC  0  on  the  Black  DART  in 

Receive/Transmit  Clock  the  OTCIXS  E  Link  Controller.  The  signal  is  output  from 

connector  J9  pin#  Ton  the  rear  connector  panel.  It  provides 
receive  and  transmit  bit  interval  timing  for  the  KG-84A 
cryptographic  units.  It  should  be  connected  to  the  negative 
clock  inputs  on  the  KG-84A  cryptographic  device.  This  signal 
is  a  software  phase-locked  version  of  the  Radio  transmit  and 
_ receive  clocks. _ _ _ _ _ 

18.  Red  Gated  Clock  This  signal  is  generated  by  the  KG-84A  cryptographic  units. 

The  KG-84A  sends  this  signal  on  J3  pin  20,  which  is  the 
receive  clock's  negative  output.  The  KG-84A  cryptos  do  not 
sate  the  receive  clock  during  a  receive  run-up  sequence. 


Table  3-2.  Data  Link  Layer  Signal  Definition  List 


SIGNAL 


DEFINITION 


1.  Data  Link  Layer  Packet 


a.  Count 


b.  Cyclic  Redundancy 
check  (CRC) 


The  Data  Link  entity  for  a  Network  message.  Provides  error 
detection  mechanism  for  messages. 

Indicates  the  number  of  bytes  in  the  INFORMATION  field. 

Provides  an  error  detection  code  for  the  Data  Link  Packet  as 
described  in  appendix  B.  Calculated  over  the  COUNT, 
END,  and  INFORMATION  fields  of  the  packet. 

Identifies  whether  this  is  the  last  packet  of  a  multipacket 
sequence. 

Part  or  all  of  a  network  message. 


c.  End 


d.  Information 
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Table  3-3 .  NCS  to  Subscriber  Signal  Definition  List 


SIGNAL 

OPERATION 

1.  Net  Control  Block  ( NCB) 
Transmission  Unit  (TU) 

A  TU  transmitted  by  the  NCS  to  control  the 
allocation  of  subscriber  accesses  to  the 

OTCIXS II  network.  The  NCB  TU  informs 
the  OTCIXS  II  subscribers  of  the  current  net 
operating  configuration. 

a.  Component  Identification  (CID) 

Identifies  the  TU  as  an  NCB  TU. 

b.  Copy 

Identifies  the  number  of  times,  including  this 
transmission,  that  this  NCB  has  been 
transmitted  in  the  current  net  cycle. 

c.  Flash  Slots 

Identifies  the  number  of  RSs  in  the  current  net 
cycle  that  are  assigned  to  Flash  message  RRs. 
Within  the  RATS,  these  slots  precede  those 
assigned  to  Immediate  message  RRs.  This  field 
is  ignored  unless  the  RATS  TYPE  field 
indicates  that  a  Normal  RATS  is  present  in  the 
current  net  cycle. 

d.  Granted  Subscriber  Identification 
(GSID) 

Identifies  the  OTCIXS  II  subscriber  that  has 
been  assigned  transmission  time  in  the  current 
net  cycle. 

e.  Hits 

Indicates  the  minimum  number  of  net  cycles, 
within  the  window  specified  by  the  WINDOW 
SIZE  field,  in  which  a  net  member  must  receive 
at  least  one  message  for  transmission  in  order 
to  predict  a  network  service  requirement. 

Choices  are  2,3,4,  and  5  net  cycles. 

f  Hours 

Identifies  the  hours  component  of  the  current 
network  time  as  maintained  by  the  NCS. 
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Table  3-3.  NCS  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL 

OPERATION 

g.  Immediate  Slots 

Identifies  the  number  of  RSs  in  the  current  net 
cycle  that  are  assigned  to  Immediate  message 

RRs.  Within  the  RATS,  these  slots  follow 
those  assigned  to  Flash  message  RRs.  This 
field  is  ignored  unless  the  RATS  TYPE  field 
indicates  that  a  Normal  RATS  is  present  in  the 
current  net  cycle. 

h.  Minutes 

Identifies  the  minutes  component  of  the  current 
network  time  as  maintained  by  the  NCS. 

i.  Mode 

Indicates  the  activity  schedules  for  this  net 
cycle.  Possible  activities  are: 

a.  Nonscheduled  transmission  of  Rash 
precedence  STU 

b.  Nonscheduled  transmission  of  Immediate 
precedence  STU 

c.  Scheduled  broadcast  transmission  of  STU 

d.  No  STU  transmission 

j.  Net  Control  Station  (NCS)  Link 
Access  Queue  (LAQ) 

Identifies  pending  requests  for  link  time 
assignment  for  STU  transmissions.  Organized 
on  a  first-come,  first-serve  (FCFS)  within 
precedence  basis,  the  entries  in  this  queue 
identify: 

a.  Requesting  subscriber 

b.  Type  of  service  requested 

c.  Number  of  transmissions  requested 

d.  Minute  at  which  transmissions  are  to 
commence  (scheduled  broadcasts  only). 
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Table  3-3.  NCS  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL 

OPERATION 

k.  Net  Control  Station  (NCS)  Link 
Access  Queue  (LAQ)  Size 

Indicates  the  number  of  entries  in  the  NCS 

LAQ  (i.e.,  the  number  of  pending  service 
requests  by  net  subscribers). 

1.  Net  Control  Station  (NCS) 

Subscriber  Identification  (SID) 

Identifies  the  OTCIXS II  subscriber  that  is 
performing  the  NCS  function. 

m.  RATS  Type 

Specifies  the  characteristics  of  the  RATS 
supported  in  this  net  cycle  are  as  followings: 

a.  A  normal  RATS  is  present  in  this  cycle 

b.  This  is  the  first  net  cycle  of  an  extended 
RATS 

c.  This  is  an  intermediate  net  cycle  of  an 
extended  RATS 

d.  This  is  the  final  net  cycle  of  an  extended 
RATS. 

n.  Scheduled  Broadcast  Status 
(SB  STATUS) 

Indicates  if  scheduled  broadcasting  is  being 
performed  in  the  current  net  cycle  and,  if  not, 
whether  scheduled  broadcasting  previously 
requested  for  the  current  net  cycle  has  been 
preempted. 

o.  Seconds 

Identifies  the  seconds  component  of  the  current 
network  time  as  maintained  by  the  NCS. 

p.  STU 1  Acknowledge 

Provides  an  acknowledgment  to  the  OTCIXS  II 
subscriber  that  transmitted  an  STU  one  net 
cycle  prior  to  the  current  one. 

q.  STU  2  Acknowledge 

Provides  an  acknowledgment  to  the  OTCIXS  II 
subscriber  that  transmitted  an  STU  two  net 
cycles  prior  to  the  current  one. 

r.  STU  3  Acknowledge 

Provides  an  acknowledgment  to  the  OTCIXS  II 
subscriber  that  transmitted  an  STU  three  net 
cycles  prior  to  the  current  one. 
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Table  3-3.  NCS  to  Subscriber  Signal  Definition  List  (cont) 


SIGNAL 

OPERATION 

s.  Time  Checksum 

Indicates  the  checksum  for  the  Hours,  Minutes, 
and  Seconds  fields.  Used  to  validate  the  time 
and  to  update  the  net  time  when  validation  is 
possible. 

t.  Transmit  Count  (XMIT  CT) 

Indicates  the  number  of  times  the  subscriber 
designated  by  the  GSID  field  is  to  transmit  its 
STU. 

u.  Window  Size 

Indicates  the  number  of  net  cycles  to  by  used  by 
network  service  in  predicting  network  service 
requirements.  Choices  are  12, 16, 20,  and  24 
net  cvcles. 

2.  Network  Message 

Provides  the  vehicle  for  transferring  a  Transport 
Message.  Also  provides  for  sequencing,  to 
permit  identification  of  missed  messages,  and 
error  detection. 

a.  Broadcast  Sequence  Number  (BSN) 

Identifies  the  sequence  number  of  the  transfer. 

All  transfers  are  sequentially  numbered  from  a 
specific  subscriber  to  permit  receiving  stations 
to  recognize  missed  messages. 

b.  Transport  Message 

The  actual  message  at  the  Transport  layer  that 
is  being  transferred  between  OTCIXS II 
subscribers.  The  format  of  the  Transport  Layer 
Message  is  as  defined  in  the  TADIXS  IDS, 
Volume  I. 

c.  Block  Check  Sequence  (BCS) 

Provides  an  error  detection  code  for  the 

Transport  Layer  message  as  described  in 
Appendix  B.  Calculated  over  all  bytes  of  the 
Transport  Message  field. 
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Table  3-3.  NCS  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL 

OPERATION 

3.  Subscriber  Transmission  Unit  (STU) 

Provides  the  transmission  entity  for  the 

Transport  layer  entities  (e  g.,  formatted 
computer-to-computer  data  and  teletype 
messages). 

a.  Component  Identification  (CID) 

Identifies  the  TU  as  an  STU. 

b.  Copy 

Identifies  the  number  of  times,  including  this 
transmission,  that  this  STU  has  been  transmitted 
in  the  current  net  cycle. 

c.  Message  Pointer  Block 

Identifies  how  many  network  messages  are 
present  in  the  STU  and,  for  each  such  message, 
a  pointer  to  the  start  of  the  message  in  the  STU. 
Also  contains  a  Pointer  Check  Sequence  (PCS), 
calculated  in  accordance  with  Appendix  B,  to 
ensure  the  validity  of  the  message  pointers. 

d.  Mode 

When  the  Reservation  (RESV)  field  indicates 
that  this  STU  contains  a  piggybacked  service 
request,  this  field  identifies  the  type  of  request 
being  made.  Possible  service  requests  are: 

a.  Nonscheduled  transmission  of  Flash 
precedence  STU  required 

b.  Nonscheduled  transmission  of  Immediate 
precedence  STU  required 

c.  Scheduled  broadcast  transmission  of  STU 
required. 

e.  More 

Indicates  if  additional  service  is  required  for 

STU  transmission  on  the  current  broadcast 
schedule  (i.e.,  the  current  scheduled  broadcast 
cannot  be  completed  in  a  single  STU). 

f.  Network  Message 

Contains  a  Transport  Message  and  a  BCS. 

Also  identifies  the  BSN  for  the  transaction. 

g.  Precedence  (PREC) 

Identifies  the  precedence  level  of  the  STU  as 
other  Immediate  or  Rash. 
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Table  3-3 .  NCS  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL 


OPERATION 


h.  Reservation  (RESV) 


Indicates  whether  this  STU  contains  a 
piggybacked  service  request. 


i.  Subscriber  Identification  (SID) 


Identifies  the  OTCIXS II  subscriber  that 
originated  the  STU  transmission. 


j.  Transmit  Count  (XMIT  CT) 


When  the  RESV  field  indicates  that  a 
piggybacked  RR  is  present,  this  field  indicates 
the  number  of  times  the  STU  referenced  by  that 
request  is  to  be  transmitted. 


k.  Transmit  Minute 


When  the  RESV  field  indicates  that  a 
piggybacked  service  request  for  a  scheduled 
broadcast  is  present,  this  field  indicates  the 
minute,  within  the  hour,  at  which  that  broadcast 


is  to  occur. 
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Table  3-4.  Subscriber  to  NCS  Signal  Definition  List 


SIGNAL 

DEFINITION 

1.  Network  Message 

Provides  the  vehicle  for  transferring  a  Transfer 
Message.  Also  provides  for  sequencing,  to 
permit  identification  of  missed  messages,  and 
error  detection. 

a.  Broadcast  Sequence 

Number  (BSN) 

Identifies  the  sequence  number  of  the  transfer. 

All  transfers  are  sequentially  numbered  from  a 
specific  subscriber  to  permit  receiving  stations 
to  recognize  missed  messages. 

b.  Transport  Message 

■ 

The  actual  message  at  the  Transport  layer  that 
is  bang  transferred  between  OTCIXS II 
subscribers.  The  format  of  the  Transport  Layer 
Message  is  as  defined  in  the  TADIXS  IDS, 
Volume  I. 

c.  Block  Check  Sequence  (BCS) 

Provides  an  error  detection  code  ft>r  the 
Transport  Layer  message  as  described  in 
Appendix  b.  Calculated  over  all  bytes  of  the 
Transoort  Messaee  field. 

2.  Reservation  Request  Transmission 

Unit  (RRTU) 

A  TU  transmitted  in  an  RS  to  request  service; 
that  is,  time  on  the  OTCIXS  II  network  to 
transmit  a  STU.  Notifies  the  NCS  that  a  net 
subscriber  requires  net  service. 

a.  Component  Identification  (CID) 

Identifies  the  TU  as  an  RRTU. 

b.  Copy 

Identifies  the  number  of  times,  including  this 
transmission,  that  this  RRTU  has  been 
transmitted  in  the  current  net  cycle. 

c.  Mode  (BCS) 

Identifies  the  type  of  request  being  made. 

Posable  service  requests  are: 

a.  Nonscheduled  transmission  of  Flash 
precedence  STU 

b.  Nonscheduled  transmission  of  Immediate 
precedence  STU 

c.  Scheduled  broadcast  transmission  of  STU 
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Table  3-4.  Subscriber  to  NCS  Signal  Definition  List  (cont.) 


SIGNAL 

d.  Retry  Count 

e.  Subscriber  Identification  (SID) 

f.  Transmit  Count  (XMIT  CT) 

g.  Transmit  Minute 


DEFINITION 

Indicates  the  number  of  times  a  subscriber  has 
attempted  net  entry  prior  to  acknowledgment 
by  the  NCS  in  the  NCB. 

Identifies  the  OTCIXS II  subscriber  that  is 
making  the  request. 

Indicates  the  number  of  times  the  subscriber 
desires  to  transmit  its  STU. 

When  the  MODE  field  indicates  that  a 
scheduled  broadcast  is  required,  this  field 
identifies  the  minute,  within  the  hour,  at  which 
that  broadcast  is  to  occur. 

Provides  the  transmission  entity  for  the 
Transport  layer  entities  (e.g.,  formatted 
computer-to-computer  data  and  teletype 
messages). 


Identifies  the  number  of  times,  including  this 
transmission,  that  this  STU  has  been 
transmitted  in  the  current  net  cycle. 

Identifies  how  many  network  messages  are 
present  in  the  STU  and,  for  each  such  message, 
a  pointer  to  the  start  of  the  message  in  the 
STU.  Also  contains  a  Pointer  Check  Sequence 
(PCS),  calculated  in  accordance  with  Appendix 
B,  to  ensure  the  validity  of  the  message  pointer. 

When  the  RESV  field  indicates  that  this  STU 
contains  a  piggybacked  service  request,  this 
field  identifies  the  type  of  request  bring  made. 
Possible  service  requests  are: 


Identifies  the  TU  as  a  STU 
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Table  3-4.  Subscriber  to  NCS  Signal  Definition  List  (cont.) 


SIGNAL 

DEFINITION 

d.  Mode  (cont.) 

a.  Nonscheduled  transmission  of  Flash 
precedence  STU  required 

b.  Nonscheduled  transmission  of  Immediate 
precedence  STU  required 

c.  Scheduled  broadcast  transmission  of  STU 
required 

d.  Nonscheduled  transmission  of  Immediate 
precedence  STU  predicted. 

e.  More 

Indicates  if  additional  service  is  required  for 

STU  transmission  on  the  current  broadcast 
schedule  (i.e.,  the  current  scheduled  broadcast 
cannot  be  completed  in  a  single  STU). 

f.  Network  Message 

Contains  a  Transport  Message  and  a  BCS. 

Also  identifies  the  BSN  for  the  transaction. 

g.  Precedence  (PREC) 

Identifies  the  precedence  level  of  the  STU  as 
either  Immediate  or  Flash. 

h.  Reservation  (RESV) 

Indicates  whether  this  STU  contains  a 
piggybacked  service  request. 

i.  Subscriber  Identification  (SID) 

Identifies  the  OTCIXS II  subscriber  that 
originated  the  STU  transmission 

j.  Transmit  Count  (XMIT  CT) 

When  the  RESV  field  indicates  that  a 
piggybacked  RR  is  present,  this  field  indicates 
the  number  of  times  the  STU  referenced  by  that 
request  is  to  be  transmitted. 

k.  Transmit  Minute 

When  the  RESV  field  indicates  that  a 
piggybacked  service  request  for  a  scheduled 
broadcast  is  present,  this  field  indicates  the 
minute,  within  the  hour,  at  which  that  broadcast 
is  to  occur. 
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Table  3-5.  Subscriber  to  Subscriber  Signal  Definition  List 


_ SIGNAL 

1.  Network  message 


_ DEFINITION _ 

Provides  the  vehicle  for  transferring  a 
Transport  Message.  Also  provides  for 
sequencing,  to  permit  identification  of  missed 
messages,  and  error  detection. 


a.  Broadcast  Sequence  Number 
(BSN) 

b.  Transport  Message 

c.  Block  Check  Sequence  (BCS) 

2.  Subscriber  Transmission  Unit  (STU) 

a.  Component  Identification  (CED) 

b.  Copy 


Identifies  the  sequence  number  of  the  transfer. 
All  transfers  are  sequentially  numbered  from  a 
specific  subscriber  to  permit  receiving  stations 
to  recognize  missed  messages. 

The  actual  message  at  the  Transport  layer  that 
is  being  transferred  between  OTCIXS II 
subscribers.  The  format  of  the  Transport 
Layer  Message  is  as  defined  in  the  TADIXS 
IDS,  Volume  I. 

Provides  an  error  detection  code  for  the 
Transport  Layer  message  as  described  in 
Appendix  B.  Calculated  over  all  bytes  of  the 
Transport  Message  field. 

Provides  the  transmission  entity  for  the 
Transport  Layer  entities  (e.g.,  formatted 
computer-to-computer  data  and  teletype 
messages). 

Identifies  the  TU  as  an  STU. 

Identifies  the  number  of  times,  including  this 
transmission;  that  this  STU  has  been 
transmitted  in  the  current  net  cycle. 


c.  Message  Pointer  Block 


Identifies  how  many  network  messages  are 
present  in  the  STU  and,  for  each  such 
message,  a  pointer  to  the  start  of  the  message 
in  the  STU.  Also  contains  a  PCS,  calculated  in 
accordance  with  Appendix  B,  to  ensure  the 
validity  of  the  message  pointers. 
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Table  3-5.  Subscriber  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL  , 

DEFINITION 

d.  Mode 

When  the  RSV  field  indicates  that  this  STU 

contains  a  piggybacked  service  request,  this 

field  identifies  the  type  of  request  being  made. 

Possible  service  requests  are: 

a.  Nonscheduled  transmission  of  Rash 
precedence  STU  required 

b.  Nonscheduled  transmission  of  Immediate 
precedence  STU  required 

c.  Scheduled  broadcast  transmission  of  STU 
required 

d.  Nonscheduled  transmission  of  Immediate 
precedence  STU  predicted. 

e.  More 

This  field  is  interpreted  by  NCS.  It  is  not 
interpreted  by  the  receiving  subscriber. 

Indicates  if  additional  service  is  required  for 

STU  transmission  on  the  current  broadcast 
schedule  (i.e.,  the  current  scheduled  broadcast 
cannot  be  completed  in  a  single  STU). 

This  field  is  interpreted  by  NCS.  It  is  not 
interpreted  by  the  receiving  subscriber. 

f  Network  Message 

Contains  a  transport  message  and  a  BCS. 

Also  identifies  the  BSN  for  the  transaction. 

g.  Precedence  (PREC) 

Identifies  the  precedence  level  of  the  STU  as 
either  Immediate  or  Rash. 

h.  Reservation  (RES  V) 

Indicates  whether  this  STU  contains  a 
piggybacked  service  request. 

i.  Subscriber  Identification  (SID) 

This  field  is  interpreted  by  NCS.  It  is  not 
interpreted  by  the  receiving  subscriber. 
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Table  3-5.  Subscriber  to  Subscriber  Signal  Definition  List  (cont.) 


SIGNAL 

DEFINITION 

j.  Transmit  Count  (XMIT  CT) 

Identifies  the  OTCIXS II  subscriber  that 
originated  the  STU  transmission. 

When  the  RES  V  field  indicates  that  a 
piggybacked  RR  is  present,  this  field  indicates 
the  number  of  times  the  STU  referenced  by  that 
request  is  to  be  transmitted. 

k.  Transmit  Minute 

This  field  is  interpreted  by  NCS.  It  is  not 
interpreted  by  the  receiving  subscriber. 

When  the  RESV  field  indicates  that  a 
piggybacked  service  request  for  a  scheduled 
broadcast  is  present,  this  field  indicates  the 
minute,  within  the  hour,  at  which  that  broadcast 
is  to  occur. 

This  field  is  interpreted  by  NCS.  It  is  not 
interpreted  bv  the  receiving  subscriber. 
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IV.  NARRATIVE  SIGNAL  FLOW  TABLE 


A.  GENERAL. 

The  section  provides  a  narrative  tabulation  by  logical  signal  groupings  of  signal  flow 
between  OTCIXS II  subscribers.  Also  included  are  the  Physical  Layer  signals  used  by  the 
OTCIXS II  Link  Controllers  (LC)  to  control  and  monitor  the: 

1.  KG-84A  cryptographic  device 

2.  TD-1271B/U  DAMA  multiplexer 

3.  AN/WSC-3/5  transceiver. 

This  tabulation  provides  a  description  of  the  signal,  flow  direction,  initiation,  response 
and  amplifying  remarks. 

B.  SIGNAL  FLOW  TABLES. 

1.  Physical  Layer. 

Table  4-1  presents  the  signal  flow  table  for  the  Physical  Layer.  The  narrative  signal 
flow  for  the  Physical  Layer  is  presented  in  the  following  logical  groupings: 

a.  Non-DAMA  Mode  Data  Transmission 

b.  Non-DAMA  Mode  Data  Reception 

c.  DAMA  Mode  Data  Transmission 

d.  DAMA  Mode  Data  Reception 

e.  Crypto  Error  Handling. 

2.  Data  Link  and  Network  Layer. 

As  described  in  section  4,  the  Data  Link  Lay^r  is  closely  tied  to  the  Network  Layer, 
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therefore  these  layers  are  presented  in  a  single  signal  flow  table.  Table  4-2  presents  the  signal 
flow  table  for  the  Data  Link  and  Network  Layers.  A  single  narrative  signal  flow.  Message 
Transfer,  for  these  layers  is  presented. 

Table  4-1.  Physical  Layer  Signal  Flow 


SIGNAL 

HESSSSSSBi 

1.  Non-DAMA 

Mode  Data 
Transmission 

a.  Keyline 

OTCIXSnLC 

Keyline  is  asserted 

The  AN/WSC-3/5 

Keyline  is 

to  AN/WSC- 

when  transmission 

transceiver 

removed 

3/5  transceiver 

of  a  TU  on  the 

generates  a  modem 

immediately 

satellite  link  is 

preamble  which  is 

following  the 

required. 

60  ms  in  duration 

completion  of  TU 

after  a  40  ms  power 
up  delay  and  pre- 

transmission. 

pares  to  receive 

For  repeated 

Transmit  Data  for 

copies  of  a  TU 

transmission. 

transmission  (i.e., 
multiple  copies  of 
a  TU  in  a  single 
net  cycle). 

Key  line  will  be 
reasserted  for 
each  copy 
transmitted. 

b.  Crypto  PREP 

OTCIXSnLC 

Crypto  PREP  will 

The  KG-84A 

Crypto  PREP  is 

to  crypto 

be  asserted 

executes  an  alarm 

received  by  the 

immediately 

check  sequence  and 

KG-84  A  as 

following  keyline 

transmits  a  crypto 

SYNC-CMD-TX. 

assertion. 

pre-amble  which 
will  be  received  by 
other  KG-84A 

The  duration  of 

cryptos  on  the 

the 

OTCIXS  n 

synchronization 

network. 

pattern  generated 
by  the  KG-84  A 
will  be 

approximately 

364  bit  times 
when  the 
baseband  data 
rate  is  2400  bps 
and  381  bit  times 
when  it  is  4800 
bps. 

Receiving  crvntos 
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■BH 1 

FROM/TO 

INITIATION 

1.  Non-DAMA 
Mode  Data 
Transmission 

a.  Keyline 

OTCDCS  n  LC 
to  AN/WSC- 
3/5  transceiver 

Keyline  is  asserted 
when  transmission 
of  a  TU  on  the 
satellite  link  is 
required. 

The  AN/WSC-3/5 
transceiver 
generates  a  modem 
preamble  which  is 

60  ms  in  duration 
after  a  40  ms  power 
up  delay  and  pre¬ 
pares  to  receive 
Transmit  Data  for 
transmission. 

Key  line  is 
removed 
immediately 
following  the 
completion  of  TU 
transmission. 

For  repeated 
copies  of  a  TU 
transmission  (i.e., 
multiple  copies  of 
a  TU  in  a  single 
net  cycle). 

Keyline  will  be 
reasserted  for 
each  copy 
transmitted. 

of  the  same  type 
as  the 

transmitting 
crypto  will 
acquire  synchron¬ 
ization  with  the 
transmitting 
crypto. 

Assertion  of 

Crypto  PREP  will 
precede  each  TU 
transmission. 
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Table  4-1 .  Physical  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Non-DAMA 
Mode  Data 
Transmission 
(cont) 

c.  Transmit  Data 
Red 

OTCIXS  n  LC 
to  crypto 

After  a  crypto¬ 
type  dependent 
delay  following 
assertion  of 

Crypto  PREP  (to 
allow  for 
transmission  of 
the  crypto 
preamble).  For 
the  KG-84A  this 
delay  is  dependent 
on  the  baseband 
data  rate 
employed  For 

2400  bps  the  delay 
must  be  at  least 

364  bit  times.  For 
4800  bps  it  must 
be  at  least  381  bit 
times. 

Crypto  performs 
encryption  of  the 
received  serial  data 
and  sends  the 
resulting  serial  data 
stream  to  the  black 
side  of  the  OTCIXS 

II  LC  as  Transmit 

Data  Black. 

Transmit  Data  Red 
is  received  by  the 
KG-84A  from  the 
red  side  of  the 
OTCIXS  II  LC  as 
TX-DPT.  For  the 
KG-84A,  the  first 
two  bytes  of 
Transmit  Data  Red 
must  be  the 

BISYNC  code  to 
permit  data 
synchronization  by 
the  receiving 
processor. 

4  Transmit  Data 
Black 

Crypto  to 
OTCIXS  II  LC 

Following  receipt 
of  serial  data 
(Transmit  Data 
Red)  by  the  crypto 
and  encryption  of 
that  data. 

Transmit  Data  Black 
is  received  from  the 
crypto  by  the  black 
side  of  the  OTCIXS 
IILC. 

Received  serial  data 
is  immediately 
forwarded  as 

Transmit  Data  to  the 
AN/WSC-3/5 
transceiver  for 
transmission. 

Transmit  Data 

Black  is  sent  by 
theKG-84Aas 
ETCT. 

e.  Transmit  Data 

OTCIXS  IILC 
to  AN/WSC- 
3/5  transceiver 

Following  receipt 
of  serial  data 
(Transmit  Data 
Black)  from  the 
Crypto. 

Received  serial  data 
is  transmitted  on  the 
OTCIXS  H  rf 
channel. 

Transmit  data  is 
received  by  the 
transceiver  from 
the  black  side  of 
the  OTCIXS  H 

LC. 
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Table  4-1 .  Physical  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

2.  Non-DAMA 
Mode  Data 
Reception 

a.  Channel  Busy 

AN/WSC-3/5 
transceiver  to 
OTCIXS  HLC 

Presence  of  a 
receive  signal  at 
the  AN/WSC-3/5 
transceiver. 

Prepare  to  receive 
the  crypto  preamble 
and  transmitted  TU. 

b.  Receive  Data 

AN/WSC-3/5 
transceiver  to 
OTCIXS  n  LC 

Presence  of  a 
receive  signal. 

Received  serial  data 
is  forwarded  to  the 
crypto  as  Receive 

Data  Black.  If 
crypto  preamble  is 
detected,  prepare  to 
receive  transmitted 

TU. 

Receive  Data  is 
received  from  the 
AN/WSC-3/5 
transceiver  by  the 
black  side  of  the 
OTCIXS  H  LC. 

c.  Receive  Data 
Black 

OTCIXSnLC 
to  crypto 

Following  receipt 
of  Receive  Data 
from  the 
AN/WSC-3/5 
transceiver. 

Crypto  performs 
decryption  of  the 
received  serial  data 
and  sends  the 
resulting  serial  data 
stream  to  the  red  side 
of  the  OTCIXS  H  LC 
as  Receive  Data  Red. 

Receive  Data 

Black  is  received 
by  the  KG-84A 
from  the  black  side 
of  the  OTCIXS  H 
LCasERCT. 

d.  Receive  Data 
Red 

Crypto  to 
OTdXSHLC 

Following  receipt 
of  serial  data 
(Receive  Data 
Black)  by  the 
crypto  and 
decryption  of  that 
data. 

Receive  Data  Red  is 
received  from  the 
crypto  by  the  red  side 
of  the  OTCIXS  HLC 
and  forwarded  to  the 
Data  Link  Layer  for 
processing. 

Receive  Data  Red 
is  sent  by  the  KG- 
84A  as  RX-DPT. 

For  the  KG-84A, 
the  detection  of  a 
BISYNC  code  wiU 
signal  the 
commencement  of 
TU  reception.  The 
BISYNC  code 
indicates  that 
modem,  crypto, 
and  data 
synchronization 
has  been  achieved. 
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Table  4-1.  Physical  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

3.DAMA 

Mode  Data 
Transmission 

a.  Slot  Time 

Mark  (STM) 

TD-1271  B/U 
to  OTCIXS  n 
LC 

Generated  by  the 
TD-1271B  every 
1.38667  seconds 
to  provide 
synchronization 
with  the  DAMA 
frame. 

The  transmission  of 
the  crypto  preamble, 
which  initiates  TU 
transmission,  is 
synchronized  with 
receipt  of  STM. 

Failure  to  receive 

STM  in  a  2-second 
interval  constitutes  a 
link  failure. 

b.  External 
Transmit 
Request 

OTCIXS  n  LC 
to  TD-1271 

B/U 

External  Transmit 
Request  is 
asserted  when 
transmission  of  a 
TU  on  the  satellite 
link  is  required. 

The  TD-1271  B/U 
prepares  to  receive 
Transmit  Data  for 
transmission. 

External  Transmit 
Request  must  be 
asserted  only  once 
for  repeated  copies  of 
a  TU  transmission 
(i.e.,  multiple  copies 
of  a  TU  in  a  single 
net  cvcleV 

c.  Crypto  PREP 

OTCIXS  n  LC 
to  KG-84A 
crypto 

Crypto  PREP  will 
be  asserted 
immediately 
following 

External  Transmit 
Request  assertion. 

The  KG-84A 
executes  an  alarm 
check  sequence 
and  transmits  a 
crypto  preamble 
which  will  be 
received  by  other 
KG-84A  cryptos 
on  the  OTCIXS  0 
network. 

' 

Crypto  PREP  is 
received  by  the  KG- 
84A  as  SYNC-CMD- 
TX. 

Each  KG-84A 
receiving  the  crypto 
preamble  will 
acquire  synchro¬ 
nization  with  the 
transmitting  KG- 
84  A. 

The  duration  of  the 
synchronization 
pattern  generated  by 
the  KG-84A  will  be 
at  least  347  bit  times 
when  the  baseband 
data  rate  is  1200  bps 
and  364  bit  times 
when  it  is  2400  bps. 
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Table  4-1.  Physical  Layer  Signal  Flow  (cont.) 


wmmsm 

FROM/TO 

INITIATION 

RESPONSE 

DAMA 

Mode  Data 

Transmission 

(cont) 

c.  Crypto  PREP 
(cont.) 

d.  Transmit  Data 

OTCIXS  H  LC 

After  a  baseband 

The  KG-84A 

Red 

to  KG-84A 

data  rate 

performs 

crypto 

dependent  delay 
following 
assertion  of 

Crypto  PREP  (to 
allow  for 
transmission  of 
the  crypto 
preamble).  For 

1200  bps  the  delay 
must  be  at  least 

347  bit  times.  For 
2400  bps  it  must 
be  at  least  364  bit 
times. 

encryption  of  the 
received  serial  data 
and  sends  the 
resulting  serial 
data  stream  to  the 
black  side  of  the 
OTCIXS  H  LC  as 
Transmit  Data 
Black. 

e.  Transmit  Data 

KG-84A 

Following  receipt 

Transmit  Data 

Black 

crypto  to 

of  serial  data 

Black  is  received 

OTCIXS  n  LC 

(Transmit  Data 
Red)  by  the  KG- 
84Aand 

encryption  of  that 
data. 

from  the  crypto  by 
the  black  side  of 
the  OTCIXS  H 

LC. 

f.  Transmit  Data 

OTCIXS  H  LC 

Following  receipt 

Received  serial 

to  TD-1271 

of  encrypted  serial 

data  is 

B/U 

data  (Transmit 

Data  Black)  from 
the  crypto. 

immediately 
forwarded  as 
Transmit  Data  to 
the  TD-1271  B/U. 

Received  serial 
data  is  transmitted 
in  the  DAMA 
timeslot. 

REMARKS 


Assertion  of  Crypto 
PREP  will  precede 
each  TU 

transmission  on  the 
satellite  link. 

Transmit  Data  Red  is 
received  by  the  KG- 
84A  from  the  red 
side  of  the  OTCIXS 
H  LC  as  TX-DPT. 

The  first  two  bytes  of 
Transmit  Data  Red 
must  be  the  BISYNC 
code  to  permit  data 
synchronization  by 
the  receiving 
processor. 


Transmit  Data  Black 
is  sent  by  the  KG- 
84A  as  ETCT. 


Transmit  data  is 
received  by  the  TD- 
1271 B/U  from  the 
black  side  of  the 
OTCIXS  n  LC. 
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Table  4-1.  Physical  Layer  Signal  Flow  (cont.) 


SIGNAL 

INITIATION 

RESPONSE 

REMARKS 

4.DAMA 

Mode  Data 
Reception 

a.  Signal 

Acquired 

(SIGACQ) 

TD-1271B/U 
to  OTCIXS  n 
LC 

Presence  of  a 
receive  signal  at 
the  TD-1271B/U 
multiplexer. 

Prepare  to  receive 
the  crypto 
preamble  and 
transmitted  TU. 

b.  Receive  Data 

TD-1271  B/U 
to  OTCIXS  n 
LC 

Presence  of  a 
receive  signal. 

Received  serial 
data  is  forwarded 
to  the  KG-84A  as 
Receive  Data 

Black.  If  crypto 
preamble  is 
detected,  prepare 
to  receive 
transmitted  TU. 

Receive  Data  is 
received  from  the 
TD-1271  B/U  by  the 
black  side  of  the 
OTCIXS  HLC. 

c.  Receive  Data 
Black 

OTCIXS  II  LC 
to  KG-84A 
crypto 

Following  receipt 
of  Receive  Data 
from  the  TD- 
1271B/U. 

The  KG-84A 
performs 
decryption  of  the 
received  serial  data 
and  sends  the 
resulting  serial 
data  stream  to  the 
red  side  of  the 
OTCIXS  H  LC  as 
Receive  Data  Red. 

Receive  Data  Black 
is  received  by  the 
KG-84A  from  the 
black  side  of  the 
OTCIXS  HLC  as 
ERCT. 

d.  Receive  Data 
Red 

Ciyptoto 
OTCIXS  n  LC 

Following  receipt 
of  serial  data 
(Receive  Data 
Black)  by  the 
crypto  and 
decryption  of  that 
data. 

Receive  Data  Red 
is  received  from 
the  crypto  by  the 
red  side  of  the 
OTCIXS  HLC 
and  forwarded  to 
the  Data  Link 

Layer  for 
processing. 

Receive  Data  Red  is 
sent  by  the  KG-84A 
as  RX-DPT. 

The  detection  of  a 
BISYNC  code  will 
signal  the 
commencement  of 

TU  reception.  The 
BISYNC  code 
indicates  that 
modem,  crypto,  and 
data  synchronization 
has  been  achieved. 

48 


Table  4-1 .  Physical  Layer  Signal  Flow  (cont.) 


■nsi 

FROM/TO 

RESPONSE 

REMARKS 

5.  Crypto  Error 
Handling 

a.  Ciypto  Alarm 
Indicate 

Ciypto  to 
OTCEXS  n  LC 

By  the  crypto  to 
indicate  that  it  is 
in  an  alarm  state. 

The  OTCIXS  H 

LC  shall  attempt 
to  clear  the  alarm 
state  by  signaling 
Crypto  Alarm 

Reset. 

If  the  crypto  still 
indicates  an  alarm 
condition  after 
three  alarm  reset 
attempts,  the 
OTCIXS  HLC 
shall  consider  the 
interface  to  be 
inoperable. 

Crypto  Alarm 

Indicate  is  sent  by 
the  KG-84  A  as  RED- 
AI. 

b.  Ciypto  Alarm 
Reset 

! 

OTCIXS  n  LC 
to  crypto 

By  OTCIXS  II  LC 
to  clear  the  alarm 
state  of  its  crypto 
indicated  by 
reception  of 

Crypto  Alarm 
Indicate. 

The  ciypto  •will 
attempt  to  clear 
the  Crypto  Alarm 
Indicate  signal  and 
take  itself  out  of 
the  alarm  state. 

Crypto  Alarm  Reset 
is  received  by  the 
KG-84A  as  RP- 
STBYR. 

The  OTCIXS  HLC 
will  continue  to 
attempt  to  clear  the 
alarm  state  until  the 
Ciypto  Alarm 

Indicate  signal  is 
removed. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS  | 

1.  Message 

Transfer 

a.  Net  Control 

Net  Control 

Sent  at  the 

The  packet  CRC  of 

Processing  of  the 

Block  (NCB) 

Station 

following  times  to 

the  Data  Link  Layer 

NCB's  triply 

Transmission 

(NCS)  to 

mark  the 

packet  containing  the 

redundant  fields  or 

Unit  (TU) 

Subscriber 

beginning  of  an 

NCB  shall  be 

of  the  HOURS, 

OTCIXS  H  net 

validated  by  calcu- 

MINUTES,  and 

cycle: 

lating  the  packet 

SECONDS  fields 

CRC  and  comparing 

(which  are  validated 

a.  Upon 

it  with  the  CRC 

against  the  TIME 

completion  of  NCS 

value  present  in  that 

CHECKSUM  field) 

initialization 

packet.  If  validation 

shall  be  performed 

processing. 

is  not  achieved,  the 

even  when  the  packet 

packet  shall  be 

CRC  cannot  be 

b.  Upon 

marked  as  bad  and 

validated. 

completion  of  an 

replaced  with  a 

idle  cycle 

packet  received  in  a 
repeat  transmission 

c.  Upon 

of  the  NCB  if  such  a 

completion  of  a 

transmission  is 

busy  cycle 

received.  After  all 
repeats  of  the  NCB 
have  been  received 
or  an  error-free  NCB 
is  received, 
processing  of  the 

NCB  shall  continue 
as  follows: 

a.  Net  Control 

Net  Control 

1.  Validate  the  NCB 

Validation  of  the 

Block  (NCB) 

Station 

triply  redundant 

triply  redundant 

Transmission 

(NCS)  to 

fields: 

fields  requires 

Unit  (TU) 
(cont.) 

Subscribers 

a.  If  validation  of  the 

obtaining  at  least  a 
two  out  of  three 

CID  field  cannot  be 
achieved,  the  NCB 

match. 

shall  be  discarded. 

The  received  TU 

In  that  case,  wait  for 

cannot  be  identified 

transmission  of 

as  an  NCB  TU  if  the 

another  NCB  TU. 

CID  value  is  invalid. 

b.  If  validation  of  the 

Processing  of  the 

NCS  SID  field  is 

NCB  shall  continue 

achieved,  perform 

even  when  the  NCS 

the  following 

SID  field  cannot  be 

operations: 

validated. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer  (cont) 

a.  Net  Control 
Block  (NCB) 
Transmission 
Unit  (TU) 

(cont.) 

Net  Control 

Station 

(NCS)to 

Subscribers 

(cont.) 

If  the  receiving  sub¬ 
scriber  is  selected  as 

NCS  (i.e.,  the  NCS 
receives  an  NCB  TU 
from  another  sub¬ 
scriber),  generate  a  Dual 
NCS  alert. 

When  an  NCS  is 
active,  all  other 
subscribers  shall  be 
prevented,  via 
software,  from 
assuming  NCS. 

a.  Net  Control 
Block  (NCB) 
Transmission 
Unit  (TU) 

(cont.) 

Net  Control 

Station 

(NCS)to 

Subscribers 

(cont.) 

If  the  value  of  the  NCS 
SID  is  the  same  as  that 
assigned  to  the  receiving 
subscriber,  generate  a 

Dual  SID  alert. 

If  the  value  of  the  NCS 
SID  is  not  the  same  as 
the  last  correct 
validation  received  on 
an  NCB  TU,  generate  a 
New  NCS  alert. 

Processing  of  NCB 

TU  shall  continue 
even  when  the 
WINDOW  SIZE  and 
HITS  fields  cannot 
be  validated. 

Processing  of  the 

NCB  shall  continue 
even  when  the  SB 
STATUS  field 
cannot  be  validated. 

If  the  receiving 
subscriber  is  not  NCS, 
record  the  net  as 
operational  with  the 
subscriber  identified  by 
the  NCS  SID  field  as  the 
NCS. 

c.  If  validation  of  the 
WINDOW  SIZE  and 
HITS  fields  is  achieved, 
update  the  current 
values  of  these  items 
with  those  in  these 
fields. 

d.  If  validation  of  the  SB 
STATUS  field  is 
achieved  and  the 
contents  of  that  field 
indicate  that  a  scheduled 
broadcast  requested  by 
the  receiving  subscriber 
has  been  preempted, 
consider  the  broadcast 
completed. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer  (cont) 

a.  Net  Control 
Block  (NCB) 
Transmission 
Unit  (TU) 

(cont.) 

Net  Control 
Station  (NCS) 
to  Subscribers 
(cont.) 

e.  If  validation  of  the 
RATS  TYPE,  and 

FLASH  and 
IMMEDIATE  SLOTS 
fields  is  achieved  and 
the  receiving  subscriber 
has  an  STU  to  transmit, 
randomly  select  an  RS 
and  send  a  RRTU  in  the 
RATS  to  request  link 
time  to  transmit  that 

STU. 

a.  Net  Control 
Block  (NCB) 
Transmission 
Unit  (TU) 

(cont.) 

Net  Control 
Station  (NCS) 
to  Subscribers 
(cont.) 

f.  If  validation  of  the 
GSED,  RATS  TYPE, 
and  FLASH  and 
IMMEDIATE  SLOTS 
fields  is  achieved  and 
the  contents  of  the  GSID 
field  matches  the  receiv¬ 
ing  subscriber's  SID,  the 
receiving  subscriber  has 
been  granted  authority 
to  transmit. 

If  an  STU  is  available 
for  transmission,  the 
receiving  subscriber 
shall  immediately  com¬ 
mence  transmission  of 
the  STU.  If  additional 
link  time  is  required,  the 
subscriber  shall  notify 
NCS  of  the  requirement 
by  piggybacking  a  ser¬ 
vice  request  in  the 
transmitted  STU. 

If  the  STU 
transmission  is  by 
scheduled  broadcast, 
NCS  shall  authorize 
transmission  by  the 
subscriber  no  more 
than  45  seconds  after 
the  scheduled  time. 

If  it  cannot,  NCS 
shall  notify  the 
subscriber  that  the 
scheduled  broadcast 
has  been  preempted. 
NCS  control  of  STU 
transmission  by 
scheduled  broadcast 
shall  be  as  described 
in  section  6. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer  (cont) 

a.  Net  Control 
Block  (NCB) 
Transmission 
Unit  (TU) 

(cont.) 

Net  Control 
Station  (NCS) 
to  Subscribers 
(cont.) 

If  the  receiving 
subscriber's  SID  does 
not  appear  in  one  of 
those  fields,  a  No  NCS 
Acknowledgement  alert 
shall  be  generated. 

b.  The  receiving 
subscriber  shall  retain 
the  LAQ  information  for 
use  in  the  event  that  the 
subscriber  must  assume 
NCS  responsibilities. 

The  LAQ 

information  shall  be 
ignored  if  validation 
of  the  Data  Link 

Layer  packet 
containing  the  NCB 
could  not  be 
achieved. 

b.  Reservation 
Request 
Transmission 
Unit  (RRTU) 

Subscriber  to 
NCS 

The  receiving  subscriber 
shall  also  validate  that 
all  its  unfulfilled 
requests  for  link  time 
are  present.  Any 
request  for  which  an 

LAQ  entry  is  not  present 
shall  be  resubmitted. 

If  a  request  was 
made  in  the 
preceding  net  cycle, 
via  an  RRTU,  and 
the  subscriber's  SID 
does  not  appear  in 
the  LAQ,  a  collision 
of  the  request  with 
that  of  another 
subscriber  has 
occurred  and  the 
subscriber  shall 
perform  the 

Contention  Resolu¬ 
tion  Algorithm 
(CRA)  as  discussed 
in  section  6. 

54 


Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


■ignmcM  tlMI 

RESPONSE 

Message 

Transfer  (cont) 
b.  Reservation 
Request 
Transmission 
Unit  (RRTU) 
(cont.) 

Subscriber  to 
NCS  (cont ) 

Following 
validation  of 
the  RATS 
TYPE, 

FLASH,  and 
IMMEDIATE 
SLOTS  fields 
of  a  received 
NCB,  the 

RRTU  is  sent 
by  a 

subscriber 
during  one  of 
the  RSs  in  the 
RATS  to 
request  link 
time  to 
transmit  a 

STU. 

The  packet  CRC  of  the 
Data  Link  Layer  packet 
containing  the  RRTU 
shall  be  validated  by 
calculating  the  packet 

CRC  and  comparing  it 
with  the  CRC  value 
present  in  that  packet. 

If  validation  is  not 
achieved,  the  packet 
shall  be  marked  as  bad 
and  replaced  with  a 
packet  received  in  a 
repeat  transmission  of 
the  RRTU  if  such  a 
transmission  is  received. 
After  all  repeats  of  the 
RRTU  have  been 
received  or  an  error-free 
RRTU  is  received, 
processing  of  the  RRTU 
shall  continue  as 
follows: 

Processing  of  the 
RRTU's  triply 
redundant  fields 
shall  be  performed 
even  when  the  packet 
CRC  cannot  be 
validated. 

b.  Reservation 
Request 
Transmission 
Unit  (RRTU) 
(cont.) 

Subscriber  to 
NCS 

1.  If  any  of  the  RRTU's 
triply  redundant  fields 
cannot  be  validated,  the 
request  shall  be  ignored. 

2.  If  validation  is 
achieved  and: 

a.  Contents  of  the  SID 
field  is  the  receiving 
station’s  SID,  the 
request  shall  be  ignored 
and  a  Dual  SID  alert 
shall  be  generated. 

Validation  of  the 
triply  redundant 
fields  requires 
obtaining  at  least  a 
two  out  of  three 
match. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATI 

ON 

RESPONSE 

REMARKS 

Message  Transfer 
(cont) 

b.  Reservation 
Request 
Transmission 

Unit  (RRTU) 
(cont.) 

Subscriber  to 
NCS  (cont.) 

b.  Request  is  a  non- 
scheduled  request,  the 
request  shall  be  placed 
in  the  LAQ  according  to 
its  precedence. 

Presence  of  the 
requester’s  SID  in 
the  LAQ  provided  in 
the  next  NCBTU 
sent  by  NCS  shall 
serve  as  acknow¬ 
ledgement  of  receipt 
of  the  request.  NCS 
processing  of 
subscriber  requests 
and  the  method  by 
which  those  requests 
are  entered  into  the 
LAQ  are  described  in 
section  6. 

! 

c.  Request  is  a  sche¬ 
duled  request,  the 
request  shall  be  placed 
in  the  LAQ  according  to 
its  precedence  but  shall 
be  unavailable  for 
selection  until  the  time 
indicated  in  the  request 
occurs.  If  the  subscriber 
.  is  already  on  the  LAQ 
with  a  scheduled 
broadcast  request,  the 
RRTU  Transmit  Minute 
shall  be  used  to  update 
the  subscriber's 
scheduled  request  entry. 

If  the  requester's  SID 
does  not  appear  in 
the  LAQ  received  in 
the  following  net 
cycle,  a  collision  of 
the  request  with  that 
of  another  subscriber 
has  occurred  and  the 
subscriber  shall 
perform  the 

Contention  Resolu¬ 
tion  Algorithm 
(CRA)  as  discussed 
in  section  6. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


IKffSSflrMI 

FROM/TO 

RESPONSE 

REMARKS 

Message 

Transfer  (cont.) 

c.  Subscriber 

NCS/Sub- 

Sent  by  a 

For  each  Data  Link 

Processing  of  the 

Transmission 

scriberto 

subscriber  in 

Layer  packet  containing 

STU  shall  be 

Unit  (STU) 

Subscriber 

response  to  the 

the  received  STU,  the 

performed  even 

receipt  of  an 

packet  CRC  shall  be 

when  all  packet 

NCBTU 

validated  by  calculating 

CRCs  cannot  be 

designating  the 

the  packet  CRC  and 

validated. 

subscriber  as  the 

comparing  it  with  the 

granted 

CRC  value  present  in 

subscriber  (i.e.. 

that  packet.  Ifvalida- 

the  GSID  field 

tion  is  not  achieved  on  a 

in  the  NCB 

packet,  that  packet  shall 

contains  the 

be  marked  as  bad  and 

subscriber's 

replaced  with  a  cones- 

SID). 

ponding  packet  received 

Sent  by  NCS 

in  a  repeat  transmission 

when  it 

of  the  STU  if  such  a 

determines  that 

transmission  is  received. 

it  is  the  granted 

After  all  repeats  of  the 

subscriber  (i.e.. 

STU  have  been  received 

it  has  placed  its 

or  an  error-free  STU  is 

SID  in  the  GSID 

received,  processing  of 

field  of  the  NCB 

the  STU  shall  continue 

for  this  net 

as  follows: 

cycle). 

l.Validate  the  STU 

Validation  of  the 

triply  redundant  fields. 

triply  redundant 
fields  requires 
obtaining  a  two 
out  of  three  match. 

a.  If  validation  of  the 

The  received  TU 

CID  field  cannot  be 

cannot  be 

achieved,  the  STU  shall 

identified  as  an 

be  discarded.  In  that 

STU  if  the  CID 

case,  wait  for  the 
transmission  of  another 
TU. 

value  is  invalid. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

REMARKS 

Message  Transfer 
(cont) 

c.  Subscriber 
Transmission 

Unit  (STU) 
(cont.) 

NCS/Sub- 
scriber  to 
Subscriber 

b.  If  validation  of  the 

SID  field  is  achieved 
and  the  SID  is  equal  to 
the  receiving  sub¬ 
scriber's  SID  generate  a 
Dual  SID  alert. 

Processing  of  the 
STU  shall  be 
performed  even 
when  the  contents 
of  the  SID  field 
cannot  be 
validated. 

c.  Subscriber 
Transmission 

Unit  (STU) 
(cont.) 

Subscriber 

toNCS 

2.  Validate  the  contents 
of  the  Message  Pointer 
Block  by  calculating  a 
CRC  on  its  fields 
(exclusive  of  the  PCS 
field)  and  comparing  it 
to  the  contents  of  the 

PCS  field.  If  a  match  is 
not  obtained,  the  entire 
STU  shall  be  discarded. 

Individual 
messages  in  the 

STU  cannot  be 
properly  delimited 
if  the  contents  of 
the  Message 

Pointer  Block 
cannot  be 
validated. 

3 .  If  the  contents  of  the 
Message  Pointer  Block 
was  validated,  use  the 
Message  Pointers  to 
extract  each  of  the 
network  messages  from 
the  STU.  If  the  message 
is  addressed  to  the 
receiving  subscriber, 
process  the  message 
accordingly.  If  STU 
reception  was  via  an 
OTCIXS  n  LC, 
formatted  computer-to- 
computer  messages  are 
transferred  to  the  TDP 
and  TTY  messages  are 
transferred  to  the 
teletype.  If  STU 
reception  was  via  an 
OTCIXS  II  LC  (within  a 
TGF),  all  messages  are 
transferred  to  the  TGP. 

Refer  to  TADIXS 
IDS  Volume  I  for 
the  format  of  the 
transport  messages 
contained  in  the 
network  messages. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


KmHH 

FROM/TO 

■ij?nmrjuw«i 

Message 

Transfer  (cont.) 

c.  Subscriber 
Transmission 
Unit  (STU) 
(cont.) 

Subscriber  to 
NCS  (cont.) 

Sent  by  a 
subscriber  in 
response  to  the 
receipt  of  an 
NCBTU 
designating  the 
subscriber  as 
the  granted 
subscriber  (i.e., 
the  GSID  field 
in  the  NCB 
contains  the 
subscriber's 

SID).  The 
transmitting 
subscriber  shall 
transmit  the 

STU  the 
number  of 
times  specified 
in  the  received 
NCBTU. 

Messages  containing 
embedded  errors  (i.e., 

CRC  at  end  of  message 
does  not  match 
computed  CRC  over 
message)  shall  be  so 
noted  when  transferred 
to  the  TDP  or  TGP. 

For  each  Data  Link 

Layer  packet  containing 
the  received  STU,  the 
packet  CRC  shall  be 
validated  by  calculating 
the  packet  CRC  and 
comparing  it  with  the 

CRC  value  present  in 
that  packet.  If  valida¬ 
tion  is  not  achieved  on  a 
packet,  that  packet  shall 
be  marked  as  bad  and 
replaced  with  a  corres¬ 
ponding  packet  received 
in  a  repeat  transmission 
of  the  STU  if  such  a 
transmission  is  received. 

After  all  repeats  of  the 
STU  have  been  received 
or  an  error-free  STU  is 
received,  processing  of 
the  STU  shall  continue 
as  follows: 

Processing  of  the 

STU  shall  be 
performed  even 
when  all  packet 

CRCs  cannot  be 
validated. 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

1.  Validate  the  STU 
triply  redundant  fields. 

Validation  of  the 
triply  redundant 
fields  requires 
obtaining  a  two 
out  of  three  match. 

Subscriber 
Transmission 
Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

a.  If  validation  of  the 

CID  field  cannot  be 
achieved,  the  STU  shall 
be  discarded.  In  that 
case,  wait  for  the 
transmission  of  another 
TU. 

The  received  TU 
cannot  be 
identified  as  an 

STU  if  the  CID 
value  is  invalid. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 
Transfer  (cont) 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

b.  If  validation  of  the 

SID  field  is  achieved 
and  the  SID  is  equal  to 
the  receiving  sub¬ 
scriber's  SID,  generate  a 
Dual  SID  alert. 

Processing  of  a 
piggy-backed  RR 
shall  not  be 
performed  if  the 
contents  of  the  SID 
field  cannot  be 
validated.  Other 
portions  of  the 

STU  shall  be 
processed  even 
when  the  contents 
of  the  SID  field 
cannot  be 
validated. 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

c.  If  validation  of  the 
RESV,  MODE,  XMIT 

CT,  TRANSMIT 
MINUTE,  and  MORE 
fields  cannot  be 
achieved,  NCS  shall  not 
perform  piggy-back  net 
service  request 
processing  on  the  STU. 

The  NCS  cannot 
identify  the 
requesting  subs¬ 
criber's 
transmission 
requirements  if 
these  fields  cannot 
be  validated 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

j 

d.  If  validation  of  the 
RESV,  MODE,  XMIT 
CT,  TRANSMIT 
MINUTE,  and  MORE 
fields  is  achieved  and 
the  contents  of  the 

RESV  field  indicates 
that  the  subscriber  has 
piggybacked  a  request 
for  additional  net 
service  in  the  STU: 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer 

(cont) 

Subscriber 
Transmission 
Unit  (STU) 

(cont) 

Subscriber  to 
NCS  (cont.) 

If  the  request  was  for 
nonscheduled  services, 
the  request  shall  be 
placed  in  the  LAQ 
according  to  its 
precedence.  Presence  of 
the  requester's  SID  in 
the  LAQ  provided  in  the 
next  NCB  TU  sent  by 

NCS  shall  serve  as 
acknowledgement  of 
receipt  of  the  request. 

NCS  processing  of 
subscriber  requests 
and  the  method  by 
which  those 
requests  are 
entered  into  the 

LAQ  are  as 
described  in 
section  6. 

Subscriber 
Transmission 
Unit  (STU) 
(cont.) 

Subscriber  to 
NCS  (cont.) 

If  the  request  is  for 
scheduled  services,  the 
request  shall  be  placed 
in  the  LAQ  according  to 
its  precedence  but  shall 
be  unavailable  for 
selection  until  the  time 
indicated  in  the  request 
occurs.  Presence  of  the 
requester's  SID  in  the 
LAQ  provided  in  the 
next  NCB  TU  sent  by 
NCS  shall  serve  as 
acknowledgement  of 
receipt  of  the  request. 

e.  If  validation  of  the 
MORE  field  is  achieved 
and  its  contents 
indicates  that  the 
requesting  subscriber 
has  an  additional  service 
requirement  for  STU 
transmission  on  the 
current  broadcast 
schedule,  the  NCS  shall 
indicate  the  requesting 
subscriber's  SID  as  the 
Granted  SID  (GSID)  in 
the  next  NCB  it  sends. 

If  a  Flash 
precedence  entry  is 
present  in  the 

LAQ  or  if  more 
than  five  minutes 
have  elapsed  since 
the  onset  of  the 
first  net  cycle 
allocated  to  this 
scheduled 
broadcast,  the 

NCS  shall  reject 
the  request  and 
indicate  the 
rejection  by 
including  a 
scheduled 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer  (cont) 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

e.  (cont.) 

broadcasting  status 
of  preempted  in 
the  next  NCB  it 
sends.  Upon 
detecting  this 
status,  subscribers 
monitoring  the 
scheduled 
broadcast  shall 
consider  the 
scheduled 
broadcast  to  be 
concluded. 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

2.  Validate  the  contents  of 
the  Message  Pointer  Block 
by  calculating  a  CRC  on 
its  fields  (exclusive  of  the 
PCS  field)  and  comparing 
it  to  the  contents  of  the 

PCS  field.  If  a  match  is 
not  obtained,  the  entire 

STU  shall  be  discarded. 

Individual 
messages  in  the 

STU  cannot  be 
properly  delimited 
if  the  contents  of 
the  Message 

Pointer  Block 
cannot  be 
validated. 

3.  If  the  contents  of  the 
Message  Pointer  Block 
was  validated,  use  the 
Message  Pointers  to 
extract  each  of  the 
network  messages  from 
the  STU.  If  the  message  is 
addressed  to  the  NCS, 
process  the  message 
accordingly.  If  STU 
reception  was  via  an 
OTCIXS II LC,  formatted 
computer-to-computer 
messages  are  transferred 
to  the  TDP  and  TTY 
messages  are  transferred 
to  the  teletype. 

Refer  to  TADIXS 
IDS  Volume  I  for 
the  format  of  the 
transport  messages 
contained  in  the 
network  messages. 
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Table  4-2.  Data  Link  and  Network  Layer  Signal  Flow  (cont.) 


FROM/TO 

INITIATION  RESPONSE 

REMARKS 

Message 

Transfer  (cont) 

Subscriber 

Transmission 

Unit  (STU) 

(cont.) 

Subscriber  to 
NCS  (cont.) 

3.  (cont.)  If  STU 
reception  was  via  an 
OTCIXS II LC  (within  a 
TGF),  all  messages  are 
transferred  to  the  TGP. 

Messages  containing 
embedded  errors  (i.e., 

CRC  at  end  of  message 
does  not  match  computed 
CRC  over  message  shall 
be  so  noted  when 
transferred  to  the  TOP  or 
TGP. 
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V.  COMMUNICATION  CONTROLS  AND  CONVENTIONS 


A.  GENERAL. 

This  section  provides  a  description  of  the  requirements  associated  with  transfer  of  data 
among  OTCIXS II  net  members.  Included  are  descriptions  and  procedures  regarding: 

1.  Communication  controls  to  provide  data  flow,  data  synchronization,  error  detection 
and  correction. 

2.  Communication  conventions  to  support  OTCIXS  II  Link  Controller  initialization 
and  information  transfer. 

OTCIXS  II  shall  operate  either  via  a  permanently  assigned  UHF-DAMA  Time 
Division  Multiple  Access  (TDMA)  baseband  slot  (i.e.,  DAMA  Mode)  or  over  an  allocated 
UHF  SATCOM  channel  (i.e.,  Non-DAMA  Mode).  The  two  modes  are  mutually 
exclusive;  a  given  net  may  operate  in  one  or  the  other  of  the  two  modes  but  not  in  both  at 
the  same  time. 

To  support  the  transfer  of  data  on  the  net,  OTCIXS  II  shall  implement  a  computer-to 
computer  protocol  which  employs  a  layering  concept  consistent  with  the  Internal  Standards 
Organization  (ISO)  reference  model.  Each  layer  builds  upon  the  services  provided  by  the 
lower  layer  and  converses  with  its  correspondent  layer  in  the  other  processor.  Figure  5-1 
illustrates  this  layering  concept. 

B.  COMMUNICATION  CONTROLS. 

The  Physical,  Data  Link,  and  Network  protocol  layers  shall  provide  the  communication 
controls  governing  transfer  of  subscriber  data  among  OTCIXS  II  net  members.  The  support 
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provided  by  each  of  these  protocol  layers  is  described  in  the  following  paragraphs. 


Figure  5-1 .  OTCIXS II  Protocol  Layers 


1.  Physical  Layer. 

The  Physical  Layer  shall  provide  the  physical  means  for  supporting  all  higher  protocol 
layers  and  consists  of  user  baseband  and  radio  frequency  (rf)  disciplines.  These  disciplines  and 
the  timing  and  sequencing  of  the  physical  layer  signals  are  described  in  the  following 
subparagraphs. 

a.  User  Baseband. 

In  DAMA  mode  of  operation,  data  shall  be  transferred  serial  synchronously  in 
accordance  with  MIL-STD-188C  at  a  baseband  data  rate  of  1200  or  2400  bps.  In 
Non-DAMA  mode  of  operation,  data  shall  be  transmitted  serial  synchronously  in  accordance 
with  MIL-STD-188C  at  a  baseband  data  rate  of 2400  or  4800  bps.  The  baseband  data  rate  to 
be  used  in  a  particular  OTCIXS  H  network  shall  be  used  by  all  members  of  that  network.  The 
data  shall  be  transmitted  in  8-bit  bytes  least  significant  bit  first.  Parity  bits  shall  not  be  used. 
For  the  KG-84A  cryptographic  device,  all  user  data  transmissions  shall  be  preceded  by 
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transmission  of  one  BISYNC  code  (two  consecutive  ASCII  SYN  (16  hexadecimal)  codes). 
b.  Radio  Frequency. 

A  given  OTCIXS  II  rf  network  shall  operate  other  over  a  permanently 
assigned  UHF-DAMA  user  slot  (DAMA  mode)  or  aver  an  assigned  UHF  Satellite 
communication  channel  (Non-DAMA  mode). 

(1).  DAMA  Mode.  All  members  of  a  given  DAMA  Mode  OTCIXS  II 


rf  network  shall: 

(a) .  Transmit  on  the  same  assigned  uplink  frequency  and  receive 
downlink  broadcasts  on  the  same  translated  downlink  frequency. 

(b) .  Transmit  baseband  data  to,  and  receive  baseband  data  from,  a 
TD-1271B/U  DAMA  device  operated  with  the  Transmit  Override  option.  The  half-duplex 
mode  of  operation  shall  be  used. 

(c) .  Use  a  KG-84A  cryptographic  device. 

The  TD-1271B/U  operates  as  a  modem  and  as  a  time  division  multi¬ 
plexer.  It  accumulates  user  baseband  data  over  1 .38667  second  frame-time  intervals  and  bursts 
the  accumulated  data  over  the  satellite  link.  These  uplink  data  bursts  are  received  from  the 
downlink,  buffered,  and  presented  at  the  original  baseband  rate.  User  baseband  data  is  buffered 
by  the  TD-1271B/U  until  it  is  time  to  present  that  data  to  the  UHF  uplink  transmit  subsystem. 
The  size  of  a  buffer  (in  bits)  depends  upon  the  user  baseband  rate  and  is  the  product  of  that  rate 
and  the  frame  time  (rounded  down  to  the  nearest  integer);  a  2400  bps  baseband  rate  employs  a 
3328-bit  buffer.  Unused  portions  of  the  buffer  are  padded  with  binary  ones  on  the  left  to  fill 
space  between  assertion  of  STM  and  reception  of  the  first  bit  of  the  user's  baseband 
transmission.  In  principle,  the  TD-1271B/U  insulates  its  user(s)  from  the  if  portion  of  the 
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satellite  communication  process  and,  in  feet,  physically  separates  those  users  from  UHF  radio 
transceiver  equipment  and  their  control  signals. 

(2).  Non-DAMA  Mode.  All  members  of  a  given  Non-DAMA  Mode 
OTCIXS II  if  network  shall: 

(a) .  Transmit  on  the  same  assigned  uplink  frequency  and  receive 
downlink  broadcasts  on  the  same  translated  downlink  frequency.  UHF  uplink  transmissions 
subject  user  baseband  data  to  differentially  encoded  Biphase  Phase  Shift  Keyed  (BPSK) 
modulation.  Appropriate  demodulation  is  applied  to  the  copied  downlink  broadcast. 

(b) .  Transmit  data  to,  and  receive  data  from,  an  AN/WSC-3(V)  or 
ANAVSC-5(V)  UHF  radio  transceiver.  The  half-duplex  mode  of  operation  shall  be  used. 

a  Signal  Tuning  and  Sequencing. 

The  timing  and  sequencing  of  the  Physical  Layer  signals  in  DAMA  and 
Non-DAMA  mode  operations  are  presented  in  the  following  subparagraphs. 

(1).  DAMA  Mode.  Figure  5-2  illustrates  the  physical  layer  signals 
employed  by  the  OTCIXS  II  Link  Controller  in  the  DAMA  mode  of  operation.  The  timing 
and  sequencing  of  these  signals  (for  anNCB)  is  shown  in  Figures  5-3  through  5-6.  Figures  5-3 
through  5-6  are  representative  of  timing  requirements  and  are  not  to  scale. 

(a).  Transmission.  Transmissions  shall  be  synchronized  with  the 
receipt  of  the  STM  from  the  DAMA  multiplexer,  which  is  generated  by  that  device  every 
1.38667  seconds.  Transmission  of  baseband  data  from  an  OTCIXS  II  station  must  commence 
1 .38667  seconds  (one  DAMA  frame  time)  before  that  baseband  data  is  burst  on  the  uplink.  A 
TD-1271B/U  user  may  transmit  continuously  over  several  frame  times;  the  continuity  of  the 
transmission  is  preserved  as  the  received  data  is  presented  at  each  TD-1271B/U  user  port.  The 
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OTCIXS II  subscriber  equipment  inventory  does  not  allow  a  transmitting  platform  to  receive 
its  own  transmission  or  even  to  be  aware  of  baseband  transmissions  initiated  at  the  preceding 
Slot  Time.  The  OTCIXS  II  Link  Controller  shall  initiate  DAMA  Mode  TU  Transmission  by 
asserting  External  Transmit  Request  (to  the  TD-1271B/U  DAMA  multiplexer)  followed  by 


Crypto  PREP  (to  the  KG-84A  cryptographic  unit). 


Figure  5-2.  DAMA  Configuration  Physical  Signals 


Upon  receipt  of  Crypto  PREP,  the  KG-84A  will  execute  an  alarm  check  sequence,  generate  its 
preamble,  and  forward  that  preamble  to  the  OTCIXS  II  Link  Controller  as  Transmit  Data 
Black.  The  OTCIXS  II  Link  Controller  shall  then  forward  the  received  crypto  preamble  to  the 
TD-1271B/U  as  Transmit  Data.  The  OTCIXS  II  Link  Controller  shall  delay  sending  its 


69 


transmit  data,  as  Transmit  Data  Red,  to  the  KG-84A  to  allow  time  for  the  KG-84A  to 


complete  execution  of  its  alarm  check  sequence  and  generation  of  its  preamble.  This  delay 
must  be  at  least  289  ms  (347  bit  times)  when  a  1200  bps  baseband  rate  is  used  and  at  least  152 


ms  (364  bit  times)  when  a  2400  bps  baseband  rate  is  used.  Upon  receipt  of  the  transmit  data. 
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Figure  5-3.  DAMA  Configuration  Physical  Signal  Timimg:  1200  pbs  KG-84A  Transmit 
the  KG-84A  will  encrypt  it  and  forward  it  to  the  OTCIXS II  Link  Controller  as  Transmit  Data 
Black.  The  OTCIXS  II  Link  Controller  shall  then  forward  the  encrypted  data  to  the 
TD-1271B/U  as  Transmit  Data. 

(b).  Reception.  The  OTCIXS  II  Link  Controller  shall  initiate  DAMA 
Mode  TU  Reception  upon  receipt  of  SIGACQ  from  the  TD-1271B/U.  Upon  receipt  of 
Receive  Data  from  the  TD-1271B/U,  the  OTCIXS  II  Link  Controller  shall  forward  the 
received  data  to  the  KG-84A  as  Receive  Data  Black.  Upon  detection  of  a  crypto  preamble, 
the  OTCIXS  II  Link  Controller  shall  prepare  to  receive  the  transmitted  TU.  After  the  KG-84A 
has  achieved  synchronization  with  the  transmitting  KG-84A  it  will  begin  decrypting  the  TU. 
The  decrypted  data  is  then  forwarded  by  the  KG-84A  to  the  OTCIXS  II  Link  Controller  as 
Receive  Data  Red. 

From  the  perspective  of  downlink  broadcast  reception,  net  cycle  slots 
are  offset  approximately  260  milliseconds  (average  uplink/downlink  propagation  time)  from  the 
uplink  burst  and  approximately  1 .65  seconds  from  the  onset  of  a  baseband  transmission  from 
an  OTCIXS  H  Link  Controller  to  its  connected  TD-1271B/U.  One  complete  DAMA  frame  is 
lost  whenever  a  station  switches  from  a  receiving  to  a  transmitting  stance.  Hence,  one  frame  is 
always  lost  after  the  NCB  is  transmitted.  At  least  one,  and  occasionally  two,  frames  are  lost 
after  each  STTS. 

(2).  Non-DAMA  Mode.  Figure  5-7  illustrates  the  physical  layer 
signals  employed  by  the  OTCIXS  II  Link  Controller  in  the  Non-DAMA  mode  of  operation. 
The  timing  and  sequencing  of  these  signals  (for  an  NCB)  is  shown  in  Figures  5-8  through  5-1 1 . 

(a).  Transmission.  The  OTCIXS  II  Link  Controller  shall  initiate 
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Non-DAMA  Mode  TU  transmission  by  asserting  Keyline  to  the  AN/WSC-3/5  transceiver. 

Immediately  following  Keyline  assertion,  the  OTCIXS  II  Link  Controller  shall  assert 
Crypto  PREP  to  the  cryptographic  unit. 

Upon  receipt  of  Crypto  PREP,  the  vCrypto  will  generate  its  preamble  (an  alarm  check 
sequence  will  also  be  executed  if  the  crypto  is  a  KG-84A)  and  pass  it  to  the  OTCIXS  II 
Link  Controller  as  Transmit  Data  Black.  The  OTCIXS  II  Link  Controller  shall  then 
forward  the  received  crypto  preamble  to  the  ANAVSC-3/5  as  Transmit  Data.  After  a 
baseband  rate  and  crypto-type  dependent  delay  following  assertion  of  Crypto  PREP  (to 
allow  for  transmission  of  the  crypto  preamble),  the  OTCIXS  II  Link  Controller  shall 
begin  sending  its  transmit  data  to  the  ciypto  as  Transmit  Data  Red.  When  the  crypto  is  a 
KG-84A,  this  delay  must  be  at  least  152  ms 

(364  bit  times)  when  the  baseband  rate  is  2400  bps  or  80  ms  (381 
bit  times)  when  the  baseband  rate  is  4800  bps.  Upon  receipt  of  the  transmit  data,  the 
crypto  will  encrypt  it  and  forward  it  to  the  OTCIXS  II  Link  Controller  as  Transmit  Data 
Black,  The  OTCIXS  II  Link  Controller  shall  then  forward  the  encrypted  data  to  the 
AN/WSC-3/5  as  Transmit  Data. 

(b).  Reception.  The  OTCIXS  II  Link  Controller  shall  initiate 
Non-DAMA  Mode  TU  Reception  upon  receipt  of  Channel  Busy  from  the  AN/WSC-3/5 
transceiver.  Upon  receipt  of  Receive  Data  from  the  AN/WSC-3/5,  the  OTCIXS  II  Link 
Controller  shall  forward  the  received  data  to  the  crypto  as  Receive  Data  Black.  Upon 
detection  of  a  crypto  preamble,  the  OTCIXS  II  Link  Controller  shall  prepare  to  receive 
the  transmitted  TU.  After  the  crypto  has  achieved  synchronization  with  the  transmitting 
ciypto,  it  will  begin  decrypting  the  TU.  The  decrypted  data  is  then  forwarded  by  the 
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crypto  to  the  OTCIXS II  Link  Controller  as  Receive  Data  Red 


Figure  5-4.  DAMA  Configuration  Physical  Signal  Timing:  1200  bps  KG84A  Receive 
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Figure  5-5.  DAMA  Configuration  Physical  Signal  Timing:  2400  bps  KG-84A  Transmit 


Figure  5-6.  DAMA  Configuration  Physical  Signal  Timing:  2400  bps  KG-84A  Receive 


Figure  5-7.  Non-DAMA  Configuration  Physical  Signals 
<L  Crypto  Error  Handling. 

Upon  receipt  of  Crypto  Alarm  Indicate,  the  OTCIXS  II  Link 
Controller  shall  attempt  to  clear  the  indicated  alarm  condition  by  asserting  Crypto  Alarm 
Reset  to  crypto.  The  crypto  will  respond  by  attempting  to  take  itself  out  of  the  alarm 
state.  If  the  crypto  can  clear  the  alarm  condition,  it  will  remove  the  Crypto  Alarm  Indicate 
signal.  If  the  crypto  cannot  clear  the  condition,  the  OTCIXS  II  Link  Controller  will 
reassert  Crypto  Alarm  Reset.  If  three  consecutive  attempts  to  clear  the  alarm  condition 
are  unsuccessful,  the  OTCIXS  II  Link  Controller  shall  report  the  interface  as  inoperable 


and  continue  attempting  to  clear  the  alarm. 
2.  Data  Link  Layer. 
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The  OTCIXS  II  data  link  layer  shall  provide  reliable  data  flow  between  the  physical 
and  network  layers.  It  shall  organize  an  outgoing  (uplink)  broadcast  data  structure  into  a 
sequence  of  100-byte  packets  and  supervise  the  output  of  each  packet  as  an  emitted  bit  stream. 
It  shall  also  reassemble  an  incoming  downlink  bit  stream  into  bytes,  then  packets,  and 
finally  into  the  original  transport  entity  that  was  broadcast.  Each  Data  Link  Layer  packet  shall 
be  100  bytes  in  length  and,  as  illustrated  in  section  7,  contain  the  following  components: 

a.  END  —  a  1-bit  flag  indicating  whether  the  packet  is  the  final  packet  of  a  multipacket 
transmission. 

b.  COUNT  —  a  7-bit  value  indicating  the  number  of  data  bytes  contained  in  the  packet. 
Legal  values  are  1  through  97.  For  multipacket  transmissions,  all  packets  except  the  final 
packet. 

c.  INFORMATION  —  an  array  of  "Byte  Count"  bytes  of  data  containing  part  or  all  of 

aTU. 

d.  CRC  —  a  2-byte  CRC  sequence  computed  over  the  Transmission  End,  Byte  Count, 
and  Data  components  of  the  packet.  The  CRC  may  be  computed  by  software  or  by  the 
ZILOG  SIO  hardware  in  the  OTCIXS  II  Link  Controller.  The  algorithm  used  to  calculate  the 
CRC  is  presented  in  Appendix  B.  shall  contain  97  bytes.  The  final  packet  may  contain  from  1 
through  97  bytes. 

The  Data  Link  layer  shall  provide  limited  error  control  by  computing  CRC  values 
for,  and  appending  those  values  to,  each  outgoing  (uplink)  packet.  As  packets  are 
reassembled  from  the  incoming  (downlink)  data  stream,  CRC  values  shall  be  computed 
and  compared  with  those  appended  to  the  packets.  Each  packet  for  which  the  values 
match  shall  be  considered  error-free.  Each  packet  for  which  the  values  do  not  match  shall 
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Figure  5-8.  Non-DAMA  Configuration  Physical  Signal  Timing:  2400  bps  KG-84A  Transmit 


Figure  5-9.  Non-DAMA  Configuration  Physical  Signal  Timing:  2400  bps  KG-84A  Receive 
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figure  5-10.  Non-DAMA  Configuration  Physical  Signal  Timing:  4800  bps  KG-84A  Transmit 


Figure  5-1 1 .  Non-DAMA  Configuration  Physical  Signal  Timing:  4800  bps  Receive 


be  flagged  as  containing  errors.  Each  received  packet,  without  regard  to  the  presence  or 
absence  of  errors,  shall  be  forwarded  to  the  network  layer. 
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3.  Network  Layer. 

The  Network  Layer  shall  provide  the  management  control  under  which  orderly  and 
reliable  exchange  of  user  information  is  permitted  to  occur.  It  involves  the  exchange  of 
control,  request,  and  subscriber  data  information  between  net  members.  The  Network  Layer 
assembles  subscriber  messages  into  STUs  for  transmission  and  extracts  them  from  STUs 
received  from  the  satellite  downlink  broadcast.  Outgoing  and  incoming  subscriber  messages 
are  passed  between  the  Network  Layer  and  the  Transport  Layer.  The  Transport  Layer  is 
beyond  the  scope  of  this  document. 

a.  Net  Cycle  Structure.  The  network  layer  partitions  channel  time  into  an 
unbounded  sequence  of  units  called  "net  cycles".  The  same  basic  net  cycle  structure  is 
employed  for  both  DAMA  and  Non-DAMA  modes  of  operation  with  differences  being  limited 
to  timing  details.  Each  net  cycle  is  subdivided  into  an  internal  structure  consisting  of  various 
combinations  of  the  following: 

1 .  GTS  --  This  time  slot  is  used  by  the  NCS  for  transmission  of  the  NCB 
to  all  net  members  to  initiate  a  net  cycle  and  convey  information  about  the  current  net 
cycle. 

2.  RATS  —  This  time  slot  is  used  by  net  members,  on  a  contention  basis,  for 
transmission  of  RRTUs.  The  RATS  is  always  present  and  consists  of  a  set  of  subintervals  call 
Request  Slots  (RS).  Except  during  net  initialization,  there  are  three  RSs,  identified  as  RSI 
through  RS3,  in  the  RATS.  During  net  initialization,  there  are  eight  RSs,  identified  as  RSI 
through  RS8,  in  the  RATS. 

3.  STTS  -  This  time  slot  is  used  by  net  members  for  transmission  of  STUs 
containing  subscriber  messages.  The  STTS  is  present  only  when  a  subscriber  transmission  has 
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been  authorized  by  the  NCS. 

Replicate  transmissions  of  data  in  these  time  slots  shall  be  used  to  increase 
the  probability  that  each  net  member,  including  the  NCS,  will  receive  at  least  one  copy  of 
whatever  is  being  broadcast.  Moreover,  in  the  case  of  STUs,  multiple  transmissions  with 
selective  packet  replacement  increases  the  probability  that  net  members  can  reconstruct 
error-free  composite  copies  of  transmitted  subscriber  data.  The  NCB  and  RR 
transmissions  per  cycle  shall  depend  upon  the  operating  mode  and  baseband  transfer  rate 
as  shown  in  Table  5-1.  The  STU  transmissions  per  cycle  shown  in  Table  5-1  represent 
default  values  for  each  combination  of  net  mode  and  baseband  rate.  The  actual  times  that 
a  STU  will  be  transmitted  shall  be  specifiable  by  the  net  member  in  the  range  of  one  to 
three. 

b.  Net  Cycle  Initiation. 

Each  net  cycle  shall  be  initiated  by  transmission  of  an  original  and  from  zero  to 
one  copies  of  the  NCB  created  by  the  NCS.  The  transmission  shall  be  preceded  by  a  fresh 
crypto  preamble,  and,  in  the  case  of  the  Non-DAMA  operating  mode,  a  fresh  modem 
preamble.  Critical  information  conveyed  by  the  NCB  shall  be  triply  NCB  shall  be  conveyed 
over  the  link  in  (i.e.,  as  a  passenger  in)  a  single  OTCIXS  H  packet.  Each  encoded  and 
receiving  net  members  shall  consider  the  contents  of  a  critical  information  field  to  be  valid 
when  two  out  of  the  three  decoded  values  are  equal.  Each  information  field  of  the  NCB  is 
treated  separately. 
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Table  5-1 .  TU  Transmissions  per  Net  Cycle 


Mode 

Baseband  Rate 

.TUI 

transmissions  per  Cvcle 

RR 

STTT 

DAMA 

1200  bps 

1 

1 

2 

DAMA 

2400  bps 

1 

2 

2 

Non-DAMA 

2400  bps 

2 

2 

2 

Non-DAMA 

4800  bps 

2 

2 

3 

Hence,  the  presence  of  bit  errors  in  a  received  NCB  shall  not  cause  that  NCB  to  be 
rejected.  The  NCB  shall  include  the  following  critical  information  fields: 

1.  CTD  -  Identifies  the  TU  as  an  NCB 

2.  COPY  -  Identifies  which  copy  of  the  NCB  has  been  received 

3.  RATS  TYPE  -  Identifies  the  type  of  RATS  supported  in  this  net  cycle 

4.  NC5LSJD  -  Identifies  the  subscriber  functioning  as  NCS 

5.  GRANTED  STD  -  Identifies  the  subscriber  (if  any)  to  whom  STTS  has  been 

allocated 

6.  XMEL.CI  -  If  STTS  has  been  allocated  to  a  subscriber  in  this  net  cycle, 
identifies  the  number  of  times  that  subscriber  is  to  transmit  a  STU  in  the  STTS 

7.  FT  ASH  ST  GTS  -  Indicates  the  number  of  Flash  precedence  RSs  in  this  net 

cycle's  RATS 

8.  IMMEDIATE  SLOTS  -  Indicates  the  number  of  Immediate  precedence 
RSs  in  this  net  cycle's  RATS 

9.  MODE  -  Identifies  the  type  of  service  provided  during  this  net  cycle 

10.  SB  STATUS.  -  Indicates  the  status  of  scheduled  broadcasting  during 
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this  net  cycle 


11.  WINDOW  STZF,  -  Indicates  the  size  of  the  window,  in  net  cycles,  to  be 
used  by  net  members  in  predicting  their  network  service  requirements 

12.  HTTS  -  Indicates  the  number  of  net  cycles,  within  the  window  specified  by 
the  WINDOW  SIZE  field,  in  which  a  net  member  must  receive  at  least  one  message  for 
transmission  in  order  to  predict  a  network  service  requirement. 

In  addition,  the  NCB  shall  include  the  current  LAQ  which  identifies  all 
outstanding  subscriber  requests  for  network  services.  The  NCB  shall  also  include  system  time 
and,  when  appropriate,  STU  acknowledgments. 

c  Net  Cycle  Types. 

OTCIXS II  shall  provide  two  cycle  types:  Idle  and  Busy. 

(1) .  Idle  Cycle.  An  idle  cycle  shall  consist  of  a  CTS  and  a  RATS.  No 
STTS  is  present.  Idle  cycles  occur  only  when  there  are  no  pending  subscriber  requests  for 
network  service.  Figure  5-12  illustrates  the  generic  structure  of  the  idle  cycle  and  its  use. 

(2) .  Busy  Cycle.  A  busy  cycle  shall  consist  of  a  CTS,  a  RATS,  and  an 
STTS.  A  busy  cycle  occurs  as  the  result  of  the  NCS  authorizing  a  net  member  to  transmit  an 
STU  in  that  cycle.  Figure  5-13  illustrates  the  generic  structure  of  the  busy  cycle  and  its  use. 

d.  Net  Cycle  Timing. 

The  detailed  time  structure  of  net  cycles  with  respect  to  DAMA  and 
Non-DAMA  mode  operations  is  presented  in  the  following  paragraphs. 

(1).  DAMA  Mode.  DAMA  mode  net  cycle  time  slot  events  shall  be 
synchronized  on  STM  signals  asserted  by  the  TD-1271B/U  Multiplexer.  Individual 
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IDLE  CYCLE 


CTS 


CTS 

GUARD 

(DAMA  only) 


RATS 


RSI 


RS2 


RS3 


EOC 

GUARD  ‘ 

(DAMA  only) 


NCR  TRANSMITTED  BY 
NCS 


RR  TRANSMITTED  BY 
STATION  2 


RR  TRANSMITTED  BY 
STATION  1 


Figure  5-12.  Idle  Cycle  Structure  and  Use 

NOTES:  1.  Each  "transmission”  shown  may  actually  involve  multiple  physical  transmissions  -  each 
preceded  by  all  required  preambles.  The  number  of  physical  transmissions  to  be  performed  is  dependent 
on  the  selected  net  operating  mode  (DAMA/Non-DAMA)  and  baseband  data  rate  as  shown  in  Table  5-1. 

2.  NCS  transmits  an  NCB  in  the  CTS  to  initiate  the  net  cycle.  The  RATS  TYPE  field  of  this 
NCB  indicates  "Normal  RATS". 

3.  Station  1  determines  that  it  has  an  STU  to  send,  randomly  selects  RS3,  and  sends  an  RRTU  in 
RS3  of  the  RATS  to  indicate  its  transmission  requirement 

4.  Station  2  determines  that  it  has  an  STU  to  send,  randomly  selects  RSI,  and  sends  an  RRTU  in 
RSI  of  the  RATS  to  indicate  its  transmission  requirement. 


transmissions  involve  integral  numbers  of  DAMA  frames  of  1 .38667  seconds  duration.  The 
CTS  occupies  one  DAMA  frame  as  does  each  RS  in  the  RATS.  The  STTS  can  occupy  more 
than  one  DAMA  frame.  DAMA  Mode  timing  details  regarding  the  CTS,  RATS,  and  STTS 
are  illustrated  in  Figures  6-14,  6-15,  and  6-16  respectively.  From  these  figures  it  can  be  seen 
that  the  minimum  net  cycle  length  in  DAMA  Mode  operation  is  6  DAMA  frames  (1  for  CTS, 
1  for  CTS  guard,  3  for  RATS,  and  1  for  End  of  Cycle  (EOC)  guard)  or  8.32  seconds 
regardless  of  baseband  rate.  Assuming  a  busy  cycle  with  three  transmissions  of  a  maximum 
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Figure  5-13.  Busy  Cycle  Structure  and  Use 


NOTES:  1.  Each  "transmission"  shown  may  actually  involve  multiple  physical  transmissions  -  each  preceded  by 
all  required  preambles.  The  number  of  physical  transmissions  to  be  performed  is  dependent  on  the  selected  net 
operating  mode  (DAMA/Non-DAMA)  and  baseband  data  rate  as  shown  in  Table  5-1 . 

2.  NCS  transmits  an  NCB  in  the  CTS  to  initiate  the  net  cycle.  The  RATS  TYPE  field  of  this  NCB  field 
indicates  "Normal  RATS". 

3.  Station  1  determines  that  it  has  an  STU  to  send,  randomly  selects  RS2,  and  sends  an  RRTU  in  RS2 
of  the  RATS  to  indicate  its  transmission  requirement. 

4.  Station  2  determines  that  it  is  the  GSID,  the  station  authorized  by  NCS  to  transmit  an  STU  in  the 
STTS  of  the  current  net  cycle,  and  commences  transmission  of  an  STU.  The  requirement  to  transmit  this  STU 
was  identified  by  station  2  through  transmission  of  an  RRTU  in  the  RATS  of  a  previous  net  cycle.  That  RRTU 
also  identified  the  number  of  times  the  subscriber  intends  to  transmit  the  STU. 

5.  If  the  GSED  is  the  NCS,  there  will  be  a  RATS  Guard  slot  following  RS3  (DAMA  only). 


length  STU,  the  maximum  net  cycle  length  is  115.09  seconds  (83  DAMA  frames)  at  a 
baseband  rate  of  2400  bps  and  220.48  seconds  (159  DAMA  frames)  at  a  baseband  rate  of 
1200  bps. 

(2).  Non-DAMA  Mode.  Since  there  is  no  buffer  delay  in  the  rf 
uplink  subsystem  in  the  Non-DAMA  operating  mode,  baseband  data  appears  at  receiving 
stations  after  the  uplink/downlink  propagation  delay.  Since  STM  signals  are  not  available, 
each  station  must  use  a  periodic  (hardware)  interval  timer  to  track  a  cycle’s  structure. 
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Non-DAMA  mode  timing  details  regarding  the  CTS,  RATS,  and  STTS  are  illustrated  in 
Figures  5-17,  5-18,  and  5-19  respectively.  From  these  figures  it  can  be  seen  that  the 
minimum  net  cycle  length  in  Non-DAMA  Mode  operation  (regardless  of  baseband  data 
rate)  is  approximately  6.4  seconds  when  the  KG-84A  is  used.  Assuming  a  busy  cycle  with 
three  trans-missions  of  a  maximum  length  STU,  the  maximum  net  cycle  length  in 
Non-DAMA  Mode  operations  is  approximately: 

(a) .  1 12.44  seconds  when  a  KG-84A  is  used  with  a  2400  bps 

baseband  rate 

(b) .  59.70  seconds  when  a  KG-84A  is  used  with  a  4800  bps 

baseband  rate 

C.  COMMUNICATION  CONVENTIONS. 

The  following  subparagraphs  describe  the  synchronization  and  data  transfer 
techniques  net  members  shall  employ  to  accomplish  timely  and  orderly  exchange  of 
subscriber  data. 

1.  Net  Participation  Modes. 

Each  member  of  an  OTCIXS  II  net  may  participate  in  one  of  two  roles;  as  the 
NCS  or  as  a  subscriber. 

a.  Net  Control  Station. 

Each  member  of  an  OTCIXS  II  rf  net,  with  the  exception  of  submarine 
subscribers,  shall,  in  addition  to  performing  subscriber  functions,  be  capable  of  functioning 
as  NCS  for  that  net.  Two  precedence  levels  are  accommodated:  Flash  and  Immediate. 
NCS  shall  provide  service  to  Flash  RRs  before  servicing  Immediate  RRs.  Requests  for 
scheduled  broadcasts  shall  be  treated  as  having  no  precedence  prior  to  the  requested 
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BUSY 


Where  Tcp,  T™*,  Tpd,  Txmit,  and  Tcts  are  defined,  in  seconds,  as  follows: 


KG-84A 

Baseband  Rate  (bps) 

1200 

2400 

Tcp  [KG-84A  preamble  +  BISYNC  code] 

0.20 

Tncb  [NCB  transmission  time] 

0.33 

Tpd  [propagation  delay  (±0.01  sec)] 

0.28 

0.26 

N  [number  of  transmissions  per  cycle] 

1 

2 

T^=Tcp+Ttt*+Tpd  [total  transmission  time] 

1.26 

1.26 

Tcts  [CTS  duration  =  1  DAMA  frame] 

1.38667 

1.38667 

Figure  5-14.  DAMA  Mode  OTCIXS  E  Timing  -  CTS 
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Where  Tcp,  Treq,  Tpd,  Tmut,  and  Tre  are  defined,  in  seconds,  as  foUows: 


KG-84A 

Baseband  ] 

Rate  [bps] 

1200 

2400 

Tcp  [KG-84A  preamble  +  BISYNC  code] 

0.20 

Treq  [RR  transmission  time] 

0.06 

Tp«j  [propagation  delay  (±0.01  sec)] 

0.28 

0.28 

N  [number  of  transmissions  per  cycle] 

1 

2 

Txmit=N*(Tcp+Treq)+Tpd  [total  transmission  time] 

.73 

.78 

Trs  [R.S  duration  =  1  DAMA  frame] 

1.38667 

1.38667 

Figure  5-15.  DAMA  Mode  OTCIXS  n  Timing  -  RATS 
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Where  Tcp,  Tsm,  Tpd,  Tnmt,  and  Tstts  are  defined,  in  seconds,  as  follows: 


KG-84A 

Baseband  Rate  tbosl 

1200 

2400 

Tcp  [KG-84A  preamble  +  BISYNC  code] 

0.35 

0.20 

Tsto  [max.  length  STU  transmission  time] 

70.00 

35.00 

Tpd  [propagation  delay  (+0.01  sec)] 

0.26 

0.26 

N  [number  of  transmissions  per  cycle] 

2 

2 

TXmt=N*(Tcp+Tstu)+TPd  [total  transmission  time] 

140.88 

70.58 

Tstts  [STTS  duration  (DAMA  frames)] 

141.44(102) 

70.72(51) 

Figure  5-16.  DAMA  Mode  OTCIXS II  Timing  —  STTS 
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Transmission 

Timing 


Reception 

Timing 


Where  Tcp,  Tmod,  TnCb,  Tpd,  Txmit,  and  Tcts  are  defined,  in  seconds,  as  follows: 


KG-84A 


Tcp  [KG-84A  preamble  +  BISYNC  code] 

Tmod  [modem  preamble] 

Tncb  [NCB  transmission  time] 

Tpd  [propagation  delay  (±0.01  sec)] 

N  [number  of  transmissions  per  cycle] 
Txmit=N*(Tcp+Tmod+Tncb)+Tpd  [total  xmit  Tcts  time] 
fCTS  duration! 


Baseband  Rate 


1200  2400 


Figure  5-17.  Non-DAMA  Mode  OTCIXS  H  Timing  -  CTS 
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Where  Tmod,  Tcp,  Treq,  Tpd,  N,  Txmit,  and  Tre  are  defined,  in  seconds,  as  follows: 


KG-84A 

Baseband 

1200 

VMSllb 

Tmod 

[modem  preamble] 

0.23 

0.12 

Tcp 

[KG-84A  preamble  +  BISYNC  code] 

0.23 

0.12 

Treq 

[RR  transmission  time] 

0.06 

0.03 

Tpd 

[propagation  delay  (±0.01  sec)] 

0.26 

0.26 

N 

[number  of  transmissions  per  cycle] 

2 

2 

TXmit=N*(Tcp+Tmod+Treq)+Tpd  [total  xmit  time] 

1.46 

1.31 

[RS  duration] 

1.60 

1.60 

Figure  5-18.  Non-DAMA  Mode  OTCIXS II  Timing  -  RATS 


Where  Tcp,  Tmod,  Tstu,  Tpd,  N,  Txmit,  and  Tstts  are  defined,  in  seconds,  as  follows: 


KG-84A 

Baseband  Rate 

1200 

Tcp 

[KG-84A  preamble  +  BISYNC  code] 

0.16 

Tmod 

[modem  preamble] 

0.10 

Tshl 

[max  length  STU  transmission  time] 

35.00 

Tpd 

[propagation  delay  (±0.01  sec)] 

0.26 

N 

[number  of  transmissions  per  cycle] 

2 

T xmit-N*  (T cp+Tmod+Tstu)+Tpd  [total  xmit  time] 

■ 

IBM 

TSTTS  durationl 

■ 

Figure  5-19.  Non-DAMA  Mode  OTCIXS II  Timing  -  STTS 


broadcast  time  and  as  having  a  precedence  level  between  Flash  and  Immediate  thereafter. 
The  OTCIXS II  network  protocol  is  not  influenced  by  the  type  of  subscriber  data 
exchanged  over  the  link. 

(1) .  SID  of  the  NCS  net  member  serving  as  NCS  shall: 

(a).  Maintain  the  following  control  information,  updating  as 
necessary  during  net  operations,  and  include  it  in  the  NCB  it  transmits  to  initiate  each  net 
cycle. 

(2) .  Current  network  time 

(3) .  SID  of  the  net  member,  if  any,  that  is  authorized  to  transmit  a 
STU  in  the  STTS  of  the  current  net  cycle  and  the  number  of  times  that  STU  is  to  be 
transmitted 


(4).  Number  of  Flash  and  Immediate  RSs  in  the  RATS  of  the 


current  net  cycle 


(5).  Type  of  service  provided  during  the  current  net  cycle,  as 


follows: 

(a) .  Nonscheduled  transmission  of  Flash  precedence  STU 

(b) .  Nonscheduled  transmission  of  Immediate  precedence  STU 

(c) .  Scheduled  broadcast  STU  transmission 

(d) .  No  STU  transmission 

(6).  Parameters  to  be  used  by  net  member  in  predicting  service 

requirements 


follows: 


(7).  Scheduled  broadcasting  status  during  the  current  net  cycle,  as 
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(a) .  Scheduled  broadcast  activity  this  cycle 

(b) .  Scheduled  broadcast  activity  for  this  cycle  delayed  by  Flash 

transmission 

(c) .  Scheduled  broadcast  activity  for  this  cycle  preempted 

(d) .  No  scheduled  broadcast  activity  this  cycle 

(8) .  Acknowledgments  for  the  last  three  STUs  transmitted  by  net 

members 

(9) .  The  list  of  RRs,  previously  submitted  by  net  subscribers,  that 
are  awaiting  service.  This  list,  called  the  LAQ,  contains  a  maximum  of  21  RRs  each 
consisting  of: 

(a) .  SID  of  the  subscriber  requesting  authorization  to  transmit  an 

STU 

(b) .  Type  of  STU  transmission  to  be  performed 

(1) .  Nonscheduled  transmission  of  Flash  precedence  STU 

(2) .  Nonscheduled  transmission  of  Immediate  precedence 

STU 

(3) .  Scheduled  broadcast  STU  transmission 

(4) .  Predicted  nonscheduled  transmission  of  Immediate 

precedence  STU 

(c) .  Minute  past  the  hour  at  which  scheduled  broadcast  is  to  be 
performed  (scheduled  broadcast  transmissions  only) 

(d) .  Number  of  times  the  subscriber  has  requested  its  STU  be 

transmitted. 
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(b) .  Receive  RRs  from  other  net  members  and,  following  validation,  queue 
and  acknowledge  those  requests.  RR  validation  shall  consist  of: 

(1) .  Identifying  the  entity  received  as  an  RR  by  means  of  its  CBD 

value. 

(2) .  Constructing  error-free  values  for  each  item  of  critical 
information  contained  in  the  request.  Each  such  item  is  triply  encoded  and  its  contents  is 
considered  valid  when  two  out  of  the  three  decoded  values  are  equal. 

(c) .  Selectively  authorize,  on  an  FCFS  within  precedence  basis,  net 
members  to  transmit  subscriber  data,  in  STUs,  on  the  net. 

(d) .  Transmit  subscriber  data,  in  STUs,  to  other  net  members.  The  member 
providing  the  Net  Control  Function  shall  indicate  a  requirement  to  transmit  an  STU  by 
creating  an  entry  at  the  end  of  the  LAQ,  within  precedence,  rather  than  broadcasting  via 
the  satellite  link. 

(e) .  Receive  subscriber  data,  in  STUs,  from  other  net  members. 

(f) .  Detect  and  report  Dual  NCS  conditions  indicated  by  reception  of 
NCBs  from  another  net  member. 

b.  Subscriber. 

Each  OTCIXS  II  net  member  other  than  the  one  serving  as  NCS 
participates  in  the  net  as  a  subscriber  only.  In  this  role  the  net  member  shall: 

a.  Receive  NCBs  sent  by  the  NCS  to  initiate  net  cycles.  In  so  doing,  the 
net  member  shall: 

(1) .  Maintain  net  cycle  synchronization 

(2) .  Detect  and  report  changes  in  the  NCS  SID  and  net  initial- 
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ization  sequences 


(3) .  Detect  and  report  the  absence  of  Net  Control  if  more  than  76 
seconds  elapse  without  receipt  of  a  recognizable  NCB  or  STU 

(4) .  Determine  when  it  is  permitted  to  transmit  RRs  or  subscriber 

data 

(5) .  Receive  system  time  from  the  NCS  and,  when  validated, 
update  its  time  accordingly 

(6) .  Receive  NCS  acknowledgments  for  previously  submitted  RRs 

(7) .  Maintain  the  current  contents  of  the  LAQ. 

(b) .  Receive  subscriber  data,  in  STUs,  from  other  net  members  in  STUs 

(c) .  Transmit  RRs  to  NCS 

(d) .  Transmit  subscriber  data,  in  STUs,  to  other  net  members  when 
specifically  authorized  by  NCS  to  do  so. 

2.  Initialization/Startup. 

Whenever  a  net  startup  occurs,  the  NCS  shall  initiate  an  Extended  RATS.  As 
illustrated  in  Figure  5-20,  the  Extended  RATS  consists  of  eight  consecutive  idle  cycles, 
each  having  an  eight  RS  RATS.  During  the  Extended  RATS,  any  slot  may  be  used  for  the 
transmission  of  RRs  without  regard  to  the  precedence  of  the  traffic  to  be  transmitted. 

On  net  initialization,  the  first  cycle's  NCB  shall  have  a  RATS  TYPE  field  value  of 
one  and  specify  an  eight  RS  RATS.  Net  members  requiring  net  services  shall  transmit 
RRs  in  the  Extended  RATS  as  follows: 

a.  The  net  cycle,  in  the  Extended  RATS,  in  which  to  transmit  shall  be  determined 
by  random  selection. 
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b.  The  RS,  in  the  previously  identified  net  cycle,  in  which  to  transmit  shall  be 
determined  by  random  selection. 

3.  RATS  Management. 

The  RATS  portion  of  the  OTCIXS  II  net  cycle  supports  the  submission  of  RRs  to 
the  NCS  by  net  subscribers.  Except  as  discussed  under  initialization/startup,  the  RATS 
for  a  net  cycle  shall  contain  three  RSs:  RSI,  RS2,  and  RS3.  NCS  shall  designate  each  of 
these  slots  as  a  Flash  Slot,  reserved  for  Flash  precedence  RRs,  or  an  Immediate  Slot, 
reserved  for  Immediate  precedence  and  Scheduled  Broadcast  RRs.  To  support  NCS 
reception  of  Flash  precedence  requests  prior  to  Immediate  precedence  requests,  RSs 
designated  as  Flash  Slots  shall  occur,  in  the  RATS,  prior  to  those  designated  as  Immediate 
Slots.  NCS  designation  of  RSs  shall  be  based  on  the  type  of  activity  that  is  to  take  place 
during  that  cycle: 

a.  During  a  busy  net  cycle  in  which  Flash  traffic  is  to  be  transmitted  in  the  STTS, 
there  shall  be  two  Flash  Slots  and  one  Immediate  Slot. 

b.  During  a  busy  net  cycle  in  which  Immediate  traffic  is  to  be  transmitted  in  the 
STTS,  there  shall  be  one  Flash  Slot  and  two  Immediate  Slots. 

c.  During  an  idle  net  cycle,  there  shall  be  one  Flash  Slot  and  two  Immediate  Slots. 
The  number  of  Flash  Slots  and  Immediate  Slots  in  a  net  cycle  is  indicated  in  the  NCB  sent 
by  the  NCS  to  initiate  that  cycle. 

4.  Link  Access  Request  Submission. 

The  following  subparagraphs  provide  details  of  the  techniques  used  by  net 
members  to  submit  their  transmission  requirements  to  the  NCS. 
a.  RRTU. 
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A  net  member  not  authorized  to  transmit  during  the  current  net  cycle's 
STTS  shall  initiate  a  request  for  link  access  by  transmitting  an  RRTU  in  an  RS  of  the 
RATS  in  a  single  OTCIXS II  data  link  layer  packet.  A  net  member  with  Flash  precedence 
traffic  to  transmit  shall  use  a  Flash  Slot  to  identify  its  transmission  requirements  to  the 
NCS.  If  more  than  one  Flash  Slot  is  available,  the  net  member  shall  randomly  select  one.  A 
net  member  with  Immediate  precedence  or  scheduled  broadcast  traffic  to  transmit  shall 
use  an  Immediate  Slot  to  identify  its  transmission  requirements  to  the  NCS.  If  more  than 
one  Immediate  Slot  is  available,  the  net  member  shall  randomly  select  one.  A  net  member 
with  traffic  to  transmit  shall  not  transmit  an  RRTU  if: 

1.  An  RR  for  nonscheduled  STU  transmission  at  the  same  precedence 
level  previously  submitted  by  that  member  is  present  in  the  LAQ 

2.  The  net  member  is  currently  executing  the  CRA  described  in  paragraph 

6.3.6. 

member  is  awaiting  service  with  respect  to  a  previously  sent  RR  for  Immediate  traffic. 

b.  Piggyback  RR. 

A  net  member  authorized  to  transmit  during  the  current  net  cycle's  STTS 
may  indicate  one  additional  request  for  link  access  by  piggybacking  an  RR  in  space 
provided  in  the  STU  format.  By  doing  so,  the  net  member  may  submit  its  request  without 
risk  of  contention  with  other  members.  In  this  way  it  is  possible  for  a  net  member  to 
request  and  be  granted  authorization  to  transmit  STUs  on  a  continuing  basis.  Piggyback 
requests  may  result  from  existing  or  predicted  service  requirements  and  can  be  used  even 
if  the  net  member  is.  A  net  member  may,  however,  submit  an  RR  for  Flash  traffic  even 
though  that  currently  executing  the  CRA  described  in  paragraph  C.6 
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(1).  Existing  Service  Requirements.  An  existing  service 
requirement  shall  exist  when  the  net  member  granted  authorization  to  transmit  a  STU: 

(a).  Has  more  messages  than  a  single  STU  can  accommodate.  In 
this  case,  the  net  member  may  use  the  STUs  piggyback  request  structure  to  indicate: 


Figure  5-20.  Extended  RATS  Structure  and  Use 


NOTES: 

L  Bach  "transmission"  shown  may  involve  multiple  physical  transmissions  -each  preceded  by  all 
required  preambles.  The  number  of  physical  transmissions  to  be  performed  is  dependent  on  the  selected 
net  operating  mode  (DAMA\Non-DAMA)  and  baseband  data  rate  as  shown  in  Table  5-1. 

2.  NCS  transmits  a  NCB  in  the  CTS  to  initiate  the  first  cycle  of  the  extended  RATS.  The  RATS 
TYPE  field  of  this  NCB  field  indicates  "Initial  Net  Cycle  of  Extended  RATS." 

3.  Station  1  determines  that  it  has  an  STU  to  send,  randomly  selects  Cycle  1  of  the  Extended 
RATS,  and  them  randomly  selects  RS8  of  the  cycle.  Since  Cycle  1  of  the  Extended  RATS  was  selected, 
station  1  sends  an  RRTU  in  RS8  of  the  RATS  of  the  current  net  cycle. 

4.  Station  3  determines  that  is  has  an  STU  to  send,  randomly  selects  Cycle  2  of  the  Extended 
RATS,  and  then  randomly  selects  RSI  of  that  cycle.  Station  3  now  awaits  for  reception  of  the  NCB 
initiating  the  second  cycle  of  the  Extended  RATS  and  sends  an  RRTU  in  RSI  of  the  RATS  of  the  net 
cycle. 
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5.  Station  2  determines  that  is  has  an  STU  to  send,  randomly  selects  Cycle  8  of  the  Extended 
RATS,  and  then  randomly  selects  RS8  of  that  cycle.  Station  2  now  waits  for  reception  of  the  NCB 
initiating  the  eighth  cycle  of  the  Extended  RATS  and  sends  an  RRTU  in  RS8  of  the  RATS 
of  that  net  cycle. 


(1) .  Additional  transmission  required  for  nonscheduled  broadcast. 

(2) .  Additional  transmission  required  for  the  current  scheduled 

broadcast. 


This  request  will  be  queued  for  service  exactly  like  any  other 
request  and,  as  a  result,  consecutive  cycle  allocations  cannot  be  guaranteed. 

(b).  Identifies  the  next  time  at  which  a  STU  is  to  be  delivered  by 

scheduled  broadcast. 

(2).  Predicted  Service  Requirements.  A  predicted  service 
requirement  shall  exist  when  the  net  member  granted  authorization  to  transmit  a  STU 
predicts  that  an  additional  nonscheduled  broadcast  transmission  requirement  is  likely  to 
exist  in  the  near  future.  This  prediction  is  based  on  the  number  of  messages  that  became 
available  for  transmission  by  that  net  member  during  the  preceding  net  cycles.  If  at  least 
one  message  became  available  for  transmission  by  the  net  member  in  at  least  M  of  the 
immediately  preceding  N  net  cycles,  that  net  member  shall  use  the  STUs  piggyback 
request  structure  to  indicate  a  predicted  service  requirement.  Values  of  M  and  N  to  be 
used  by  the  net  members  in  their  service  requirement  predictions  are  provided  by  the  NCS 
in  the  HIT  and  WINDOW  fields,  respectively,  of  each  NCB.  If  M=2  and  N=16,  for 
example,  a  predicted  service  requirement  would  exist  if  at  least  one  message  became 
available  for  transmission  by  the  net  member  during  2  or  more  of  the  preceding  16  net 
cycles. 
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5.  Link  Access  Request  Reception. 

To  receive  RR  forwarded  by  net  members,  the  NCS  shall  copy  all  RRTUs 
transmitted  during  the  RATS  and,  for  the  purpose  of  identifying  piggyback  RRs,  all  STUs 
transmitted  during  the  STTS.  RRs  shall  be  validated  and  processed  based  on  the  type  of 
service  requested.  As  previously  indicated,  the  LAQ  shall  contain  up  to  21  entries  each 
indicating  an  RR,  previously  submitted  by  a  net  member,  that  is  awaiting  service.  Of  these 
entries,  19  shall  be  used  for  RRs  without  regard  to  service  type  requested.  While  these  19 
entries  are  full,  the  NCS  shall  discard  RRs  that  do  not  indicate  nonscheduled  transmission 
of  Flash  precedence  STU.  Two  entries  in  the  LAQ  shall  be  reserved  exclusively  for  RRs 
indicating  nonscheduled  transmission  of  Flash  prece-dence  STU. 

Each  RR  made  by  a  net  member  shall  be  acknowledged  by  NCS  through  inclusion 
of  the  net  member's  SID  in  the  LAQ  which  is  provided  in  the  NCB.  If  a  net  member  does 
not  observe  its  SID  in  the  LAQ  in  the  next  NCB,  the  request  collided  with  a  request 
submitted  by  an-other  net  member  in  the  same  RS  or  no  entries  in  the  LAQ  were  available 
to  support  the  type  of  service  requested.  In  either  event,  the  net  member  shall  execute  the 
CRA  described  in  paragraph  6.3.6. 

a.  Nonscheduled  Transmission  of  Flash  Precedence  STU. 

If  an  RR  indicating  a  requirement  for  nonscheduled  transmission  of  a  Flash 
precedence  STU  is  received,  the  NCS  shall  examine  the  LAQ  for  the  net  member 
submitting  the  request  to  determine  if  an  entry  for  that  member  currently  exists.  If  one 
does  not  exist,  an  entry  shall  be  created  that  contains  the  newly  received  RR.  If  an  entiy 
already  exists  and  that  entry  indicates: 

1.  Nonscheduled  transmission  of  Flash  precedence  STU,  the  NCS  shall 
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discard  the  newly  received  RR  as  a  duplicate. 

2.  Scheduled  Broadcast  STU  transmission,  the  NCS  shall  create  an  entry 
for  the  newly  received  RR. 

If  the  RR  was  submitted  by  piggyback  and  indicated  a  predicted  service 
requirement,  the  NCS  shall  delay  entering  the  request  in  the  LAQ  for  one  net  cycle.  This 
delay  improves  the  likelihood  that  the  subscriber  predicting  a  service  requirement  will  have 
a  message  ready  for  transmission  when  the  NCS  selects  the  request  from  the  LAQ. 

b.  Nonscheduled  Transmission  of  Immediate  Precedence  STU. 

If  an  RR  indicating  a  requirement  for  nonscheduled  transmission  of  an 
Immediate  precedence  STU  is  received,  the  NCS  shall  examine  the  LAQ  for  the  net 
member  submitting  the  request  to  determine  if  an  entry  for  that  member  currently  exists. 

If  one  does  not  exist,  an  entry  shall  be  created  that  contains  the  newly  received  RR.  If  an 
entry  already  exists  and  that  entry  indicates: 

1.  Nonscheduled  transmission  of  Immediate  precedence  STU,  the  NCS 
shall  discard  the  newly  received  RR  as  a  duplicate. 

2.  Scheduled  Broadcast  STU  transmission,  the  NCS  shall  create  an  entry 
for  the  newly  received  RR.  If  the  RR  was  submitted  by  piggyback  and  indicated  a 
predicted  service  requirement,  the  NCS  shall  delay  entering  the  request  in  the  LAQ  for 
one  net  cycle.  This  delay  improves  the  likelihood  that  the  subscriber  predicting  a  service 
requirement  will  have  a  message  ready  for  transmission  when  the  NCS  selects  the  request 
from  the  LAQ. 

a  Scheduled  Broadcast  STU  Transmission  STU. 

If  an  RR  indicating  a  requirement  for  scheduled  broadcast  STU 
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transmission  is  received,  the  NCS  shall  examine  the  LAQ  for  the  net  member  submitting 
the  request  to  determine  if  a  scheduled  broadcast  entry  for  that  member  already  exists.  If 
an  entry  already  exists,  the  broadcast  minute  from  the  new  request  shall  replace  the 
broadcast  minute  of  the  LAQ  entry.  If  an  entry  does  not  exist,  the  NCS  shall  create  an 
entry  in  the  LAQ  for  the  newly  received  Scheduled  Broadcast  request. 

6.  Contention  Resolution  Algorithm. 

When  more  than  one  net  member  transmits  an  RR  in  the  same  RS,  the  resulting 
collision  is  referred  to  as  contention  for  that  given  RS.  When  a  net  member  transmitting 
an  RR  fails  to  locate  its  SID  in  the  LAQ  included  in  the  next  cycle's  NCB,  contention  has 
occurred  and  that  net  member  must  execute  a  CRA.  The  CRA  consists  of  randomly 
selecting  the  number  of  net  cycles  the  member  must  delay  prior  to  retransmitting  the  RR. 
For  RRs  involving  nonscheduled  transmission  of  Flash  precedence  STU,  the  range  of 
cycles  to  delay  shall  be  0-7  cycles.  For  all  other  RRs,  the  range  of  cycles  to  delay  shall  be 
0-15.  If  the  net  member  is  granted  authorization  to  transmit  an  STU  prior  to  completion 
of  the  CRA,  the  CRA  shall  be  terminated  if  the  net  member  is  able  to  piggyback  the  RR 
involved  to  that  STU. 

7.  Link  Access  Request  Servicing. 

Prior  to  the  initiation  of  each  net  cycle,  the  NCS  shall  examine  the  contents  of  its 
LAQ  to  identify  if  any  RRs  are  awaiting  service.  If  not,  the  NCB  sent  by  the  NCS  to 
initiate  the  next  net  cycle  shall  indicate  an  idle  cycle  with  no  STU  transmission  and  mark 
the  scheduled  broadcast  status  as  not  active.  In  addition,  the  contents  of  the  GSID  field  of 
that  NCB  shall  indicate  that  no  net  member  has  been  authorized  to  transmit  in  the  STTS. 

If  at  least  one  RR  is  present,  NCS  shall: 
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a.  Examine  each  RR  in  the  LAQ  requesting  scheduled  broadcast  STU 
transmission.  NCS  shall: 

1 .  Purge  those  that  were  not  serviced  within  45  seconds  of  their  indicated 
transmission  time  and  mark  the  scheduled  broadcast  status  of  the  next  net  cycle  as 
preempted  by  Flash  traffic. 

2.  Mark  as  available  for  servicing  any  such  request  whose  indicated 
transmission  time  has  just  arrived. 

b.  Attempt  to  service  a  Flash  request.  If  at  least  one  is  present,  the  NCS  shall 
mark  the  next  net  cycle  as  nonscheduled  transmission  of  Flash  precedence  STU  and  select 
the  Flash  request  that  has  been  in  queue  the  longest  for  service.  The  NCS  shall  identify 
the  net  member  submitting  that  request  as  authorized  to  transmit  in  the  STTS  of  the  next 
net  cycle  and  purge  the  request  from  the  LAQ.  If  at  least  one  scheduled  broadcast  request 
is  marked  as  available  for  servicing,  the  NCS  shall  mark  the  scheduled  broadcast  status  of 
the  next  cycle  as  delayed  by  Flash  traffic.  If  not,  the  NCS  will  mark  the  scheduled 
broadcast  status  of  the  next  cycle  as  not  active. 

c.  If  no  Flash  requests  are  present,  attempt  to  service  a  scheduled  broadcast 
request.  If  at  least  one  is  present  that  is  marked  as  available  for  servicing,  the  NCS  shall 
mark  the  next  net  cycle  as  scheduled  broadcast  STU  transmission  and  select  the  scheduled 
broadcast  request  that  has  been  in  queue  the  longest  for  service.  The  NCS  shall  identify 
the  net  member  submitting  that  request  as  authorized  to  transmit  in  the  STTS  of  the  next 
net  cycle  and  purge  the  request  from  the  LAQ.  The  NCS  shall  also  mark  the  scheduled 
broadcast  status  of  the  next  net  cycle  as  active. 

d.  If  no  Flash  requests  or  scheduled  broadcast  requests  marked  as  available  for 
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servicing  are  present,  attempt  to  service  an  Immediate  request.  If  at  least  one  is  present, 
the  NCS  shall  mark  the  next  net  cycle  as  nonscheduled  transmission  of  Immediate 
precedence  STU  and  select  the  Immediate  request  that  has  been  in  queue  the  longest  for 
service.  The  NCS  shall  identify  the  net  member  submitting  that  request  as  authorized  to 
transmit  in  the  STTS  of  the  next  net  cycle  and  purge  the  request  from  the  LAQ.  The  NCS 
shall  also  mark  the  scheduled  broadcast  status  of  the  next  net  cycle  as  not  active. 

e.  If  no  request  can  be  serviced  this  net  cycle,  mark  the  next  net  cycle  as  an  idle 
cycle  with  no  STU  transmission  and  mark  the  scheduled  broadcast  status  as  not  active.  In 
addition,  the  NCS  shall  indicate  that  no  net  member  has  been  authorized  to  transmit  in  the 
STTS  of  the  next  net  cycle. 

The  NCS  shall  allocate  exactly  one  STTS  per  RR.  The  NCB  initiating  a  busy  net 
cycle  shall  identify  the  net  member  to  whom  the  STTS  is  allocated,  the  number  of  times 
the  STU  will  be  transmitted,  the  type  of  service  provided  during  the  net  cycle,  and  the 
status  of  scheduled  broadcasting  during  the  net  cycle.  Only  that  net  member  to  whom  the 
cycle  is  allocated  shall  be  permitted  to  transmit  in  the  STTS  and  the  sequence  of 
transmissions,  once  begun,  cannot  be  preempted. 

8.  Subscriber  Data  Transmission. 

When  a  net  member  receives  an  NCB  identifying  its  SID  as  the  authorized 
transmitter  during  the  STTS  of  the  current  net  cycle,  the  net  member  shall  compose  its 
STU  and  commence  transmission  of  that  STU  within  2  seconds  of  the  onset  of  the  STTS. 
STU  composition  and  transmission  shall  be  performed  as  follows: 

a.  The  net  member  shall  determine  the  type  of  transmission  being  authorized 
during  this  net  cycle  from  the  MODE  field  of  the  NCB  initiating  the  cycle. 
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b.  If  no  Transport  Layer  messages  are  available  for  transmission,  an  empty  STU 
shall  be  composed  and  transmitted. 

c.  The  net  member  shall  determine  which  of  the  Transport  Layer  messages 
available  for  transmission  are  to  be  included  in  this  STU  as  follows, 

1 .  Flash  precedence  STU  transmission  authorized.  Flash  precedence 
messages  shall  be  selected  for  inclusion  on  a  FIFO  basis.  Message  selection  shall  continue 
until  all  Flash  precedence  messages  have  been  selected  or  the  space  available  in  the  STU 
for  conveying  Network  messages  has  been  exhausted. 

2.  Immediate  precedence  STU  transmission  authorized.  Message  selection 
shall  depend  on  whether  any  Flash  precedence  messages  are  available  for  transmission,  as 
follows: 

(a) .  Flash  precedence  messages  available.  Flash  precedence 
messages  shall  be  selected  for  inclusion  on  a  FIFO  basis.  Message  selection  shall  continue 
until  all  Flash  precedence  messages  have  been  selected  or  the  space  available  in  the  STU 
for  conveying  Network  messages  has  been  exhausted.  An  RR  shall  be  piggybacked  in  the 
STU  to  re-request  transmission  authorization  for  the  Immediate  precedence  messages 
whose  transmission  was  deferred. 

(b) .  Flash  precedence  messages  not  available.  Immediate 
precedence  messages  shall  be  selected  for  inclusion  on  a  FIFO  basis.  Message  selection 
shall  continue  until  all  Immediate  precedence  messages  have  been  selected  or  the  space 
available  in  the  STU  for  conveying  Network  messages  has  been  exhausted. 

d.  Each  Transport  Layer  message  selected  for  inclusion  in  the  STU  shall  be 
incorporated  into  a  Network  message  and  a  BSN  shqll  be  assigned  to  that  message  for 
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identification.  BSNs  shall  be  assigned  sequentially  to  support  link  accountability  and 
identification  of  missed  messages. 

e.  The  Network  messages  resulting  from  the  preceding  step  shall  be  assembled 
into  the  STU.  A  Message  Pointer  Block  shall  be  constructed  to  define,  explicitly,  the 
starting  positions  of  each  Network  message  in  the  STU.  Due  to  the  critical  nature  of  its 
contents,  the  Message  Pointer  Block  shall  be  terminated  by  a  PCS.  The  PCS  shall  be  a 
CRC  sequence  calculated  as  described  in  Appendix  B. 

Net  members  receiving  this  STU  shall  use  the  PCS  to  validate  the  contents  of  the 
Message  Pointer  Block  and,  as  a  result,  their  ability  to  delimit  the  Network  messages  in 
the  STU  properly. 

f.  If  an  existing  or  predicted  service  requirement  exists,  the  net  member  shall 
piggyback  an  RR  to  the  STU.  To  accomplish  this,  the  RESV  field  of  the  STU  shall 
indicate  the  presence  of  such  a  requirement.  The  MODE  field  shall  identify  the  type  of 
service  request  being  piggybacked  to  this  STU,  and  the  XMIT  CT  field  shall  indicate  the 
number  of  times  the  STU  in  the  piggybacked  RR  is  to  be  broadcast.  If  the  requested 
service  is  scheduled  broadcast  STU  transmission,  the  TRANSMIT  MINUTE  shall  indicate 
the  minute  within  the  hour  at  which  the  scheduled  broadcast  is  to  occur. 

g.  The  MORE  field  of  the  STU  shall  indicate  a  requirement  for  additional  net 
services  under  the  current  broadcast  if: 

1 .  The  STU  under  construction  is  to  be  transmitted  by  scheduled 

broadcast 

2.  More  messages  are  available  for  transmission  on  the  broadcast  than  can 
be  accommodated  in  a  single  STU 
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3.  The  total  amount  of  transmit  time  on  the  scheduled  broadcast,  including 
the  services  being  indicated  in  this  request,  will  not  exceed  five  minutes. 

h.  The  STU  shall  be  forwarded  to  the  Data  Link  Layer  for  decomposition  into  a 
series  of  100-byte  data  link  packets  and  transmission  via  the  assigned  satellite  channel. 

The  STU  shall  be  transmitted  in  its  entirety  and,  in  most  instances,  transmitted  up  to  two 
more  times  in  succession  in  this  net  cycle;  the  actual  number  of  repeats  is  an 
operator-selectable  option.  The  COPY  field  in  each  transmission  shall  uniquely  identify 
each  transmission  of  the  STU  in  the  STTS. 

A  special  situation  arises  when  the  station  transmitting  a  STU  is  also  the 
designated  NCS.  In  such  instances,  the  NCS  shall  delay  at  least  500  milliseconds  before 
initiating  the  next  net  cycle  to  accommodate  uplink/downlink  propagation  and  provide 
time  for  net  members  to  finalize  the  STU  reception  process  and  prepare  to  receive  the  next 
cycle's  NCB. 

9.  Subscriber  Data  Reception. 

Each  net  member,  including  NCS,  copying  the  downlink  STTS  broadcast  shall 
attempt  to  reconstruct  an  error-free  composite  copy  of  the  STU  from  the  incoming  packet 
stream  using  selective  packet  replacement  when  more  than  one  transmission  of  the  STU  in 
the  STTS  has  been  performed.  As  soon  as  an  error-free  composite  copy  has  been 
constructed  or  all  transmissions  of  the  STU  have  been  received,  processing  of  the  STU 
shall  commence  as  described  in  the  following  subparagraphs. 

a.  Subscriber. 

Each  member  participating  in  the  net  as  a  subscriber  shall: 

1.  Attempt  to  validate  the  triply  encoded  CID  and  SID  fields  of  the  STU. 
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Since  the  CID  field  of  the  STU  identifies  the  type,  and  hence  structure,  of  the  received 
TU,  the  received  STU  shall  be  discarded  if  the  CID  field  cannot  be  validated.  If  validation 
of  the  SID  field  is  achieved  and  the  SID  is  equal  to  the  receiver's  SID,  a  Dual  SID  alert 
shall  be  generated. 

2.  Attempt  to  validate  the  contents  of  the  Message  Pointer  Block  in  the 
STU  by  calculating  a  CRC  on  its  fields,  exclusive  of  the  PCS  field,  and  comparing  it  to  the 
contents  of  the  PCS  field.  The  algorithm  used  to  calculate  this  CRC  is  described  in 
Appendix  B.  If  a  match  is  not  obtained,  the  STU  shall  be  discarded  since  the  individual 
network  messages  in  the  STU  cannot  be  properly  delimited. 

3.  If  the  contents  of  the  Message  Pointer  Block  is  valid,  each  network 
message  in  the  STU  shall  be  extracted  and  forwarded  to  the  Transport  Layer. 

b.  Net  Control  Station. 

In  addition  to  performing  all  processing  required  for  the  Subscriber 
participation  mode,  the  member  serving  as  theNCS  shall  acknowledge  receipt  of  the  STU, 
Attempt  to  allocate  additional  net  cycles  to  net  members  performing  scheduled  broadcast 
STU  transmission  when  necessary  to  complete  that  broadcast  and  identify  and  process  an 
RR  piggybacked  to  the  STU. 

(1).  STU  Acknowledgment.  To  acknowledge  receipt  of  an  STU 
via  the  downlink  broadcast,  the  NCS  shall  update  its  control  information  as  follows: 

(a) .  The  SID  of  the  net  member  shown  in  the  STU  3  Acknowledge 
field  of  the  NCB  transmitted  in  the  preceding  net  cycle  shall  be  discarded. 

(b) .  The  SID  of  the  net  member  shown  in  the  STU  2  Acknowledge 
field  of  the  NCB  transmitted  in  the  preceding  net  cycle  shall  be  placed  in  the  STU  3 


111 


Acknowledge  field  of  the  next  NCB  to  be  sent. 


(c) .  The  SID  of  the  net  member  shown  in  the  STU  1  Acknowledge 
field  of  the  NCB  transmitted  in  the  preceding  net  cycle  shall  be  placed  in  the  STU  2 
Acknowledge  field  of  the  next  NCB  to  be  sent. 

(d) .  The  SID  of  the  net  member  transmitting  the  received  STU 
shall  be  placed  in  the  STU  1  Acknowledge  field  of  the  next  NCB  to  be  sent.  If  the  SID 
field  of  the  received  STU  could  not  be  validated,  the  STU  1  Acknowledge  field  will 
indicate  that  no  subscriber  is  being  acknowledged. 

(2).  Scheduled  Broadcast  Continuation.  If  the  received  STU  was 
transmitted  by  scheduled  broadcast  and  the  MORE  field  of  the  STU  indicates  that 
additional  service  is  required  for  STU  transmission  on  the  current  broadcast  schedule,  the 
NCS  shall  examine  its  LAQ  and: 

(a) .  If  no  Flash  precedence  RRs  are  present  and  if  less  than  5 
minutes  (maximum)  have  elapsed  since  the  onset  of  the  first  net  cycle  allocated  to  this 
scheduled  broadcast.  The  NCS  shall  authorize  the  net  member  indicated  in  the  SID  field  to 
continue  the  scheduled  broadcast  in  the  next  net  cycle.  NCS  shall  indicate  this 
authorization  by  using  the  net  member's  SID  in  the  GSID  field  in  the  next  NCB  to  be  sent. 

(b) .  If  a  Flash  precedence  RR  is  present  or  if  more  than  5  minutes 
have  elapsed  since  the  onset  of  the  first  net  cycle  allocated  to  this  scheduled  broadcast,  the 
NCS  shall  reject  the  request  for  scheduled  broadcast  continuation.  The  NCS  shall  notify 
the  requesting  net  member  of  the  rejection  by  setting  the  SB  STATUS  field  in  the  next 
NCB  to  be  sent  to  indicate  that  scheduled  broadcasting  has  been  preempted.  In  addition, 
net  members  monitoring  the  scheduled  broadcast  shall  determine  from  the  preemption 


112 


indication  that  the  scheduled  broadcast  has  ended. 

(3).  Piggyback  Request  Identification.  To  support  submission  of 
RRs  via  STU  piggyback,  the  NCS  shall: 

(a) .  If  the  SID  field  of  the  STU  could  not  be  validated,  discontinue 
processing  of  the  STU  for  purposes  of  identifying  piggybacked  service  requests. 

(b) .  When  the  criteria  described  in  paragraph  C.9.2.2  are  met, 
support  continuation  of  a  net  member's  scheduled  broadcast. 

(c) .  If  the  RESV  field  indicates  the  presence  of  a  piggybacked  RR, 
attempt  to  validate  the  triply  encoded  MODE,  TRANSMIT  MINUTE,  and  XMIT  CT 
fields  of  the  STU.  Since  these  fields  identify  the  characteristics  of  the  requested  net 
service,  processing  of  the  STU  for  purposes  of  identifying  piggybacked  service  requests 
shall  be  discontinued  if  any  of  these  fields  cannot  be  validated.  If  these  fields  are 
validated,  the  RR  shall  be  added  to  the  LAQ  as  discussed  in  the  Link  Access  Request 
Reception  description. 

10.  Transfer  of  NCS  Responsibilities. 

The  OTCIXS  II  protocol  contains  no  provisions  for  transferring  NCS 
responsibilities  automatically.  The  role  of  NCS  is  assumed  or  relinquished  on  operator 
command  under  direction  of  Fleet  and  Theater  commanders.  Each  net  member  capable  of 
assuming  the  role  of  NCS  copies  and  maintains  the  current  LAQ  sent  by  the  current  NCS 
in  each  received  NCB.  This  process  provides  the  necessaiy  information  to  each  net 
member  to  enable  that  member  to  assume  the  role  of  NCS  and  resume  net  operations 
without  performing  the  regular  net  initialization  sequence. 
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VL  DATA  UNIT  DESCRIPTIONS 


A.  GENERAL. 

This  section  provides  a  detailed  description  of  the  content  and  format  of  the  signals 
exchanged  between  OTCIXS II  subscribers.  Each  description  consists  of  a  figure,  pictorially 
representing  the  position  of  the  various  fields,  followed  by  a  table  explaining  and  clarifying  each 
field.  All  numbers  are  in  hexadecimal  unless  specified  otherwise.  Legal  values  are  identified 
for  each  field  which  does  not  permit  the  full  range  of  legal  values  represented  by  the  field. 

Fields  which  do  not  include  the  identification  of  legal  values  can  contain  any  value  which  can  be 
represented  by  the  field  size  (i.e.,  a  byte  can  contain  values  0  through  FF). 


B.  DATA  UNIT  DESCRIPTION  -  NET  CONTROL  STATION  TO  SUBSCRIBER 

Table  6-1  summarizes  the  data  units  transferred  from  the  OTCIXS  II NCS  and  an  OTCIXS  IT 
subscriber. 


Table  6-1 .  Net  Control  Station  to  Subscriber  Data  Unit  Summary 


DATA  UNIT  NAME 

COMPONENT 

ID 

FIGURE 

Net  Control  Block  (NCB)  Transmission  Unit  (TU) 

B 

6-1 

Subscriber  Transmission  Unit  (STU) 

D 

6-3 

Network  Message 

- 

6-4 

Data  Link  Layer  Packet 

- 

6-5 
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C.  DATA  UNIT  DESCRIPTION  -  SUBSCRIBER  TO  NET  CONTROL  STATION. 
Table  6-2  summarizes  the  data  units  transferred  from  an  OTCIXS II  subscriber  to  the 
OTCIXSnNCS. 


Table  6-2.  Subscriber  to  Net  Control  Station  Data  Unit  Summary 


DATA  UNIT  NAME 

COMPONENT 

ID 

FIGURE 

Reservation  Request  (RR)  Transmission  Unit 

C 

6-2 

(RRTU) 

D 

6-3 

Subscriber  Transmission  Unit  (STU) 

■- 

6-4 

Network  Message 

- 

6-5 

Data  Link  Layer  Packet 

D.  DATA  UNIT  DESCRIPTION  -  SUBSCRIBER  TO  SUBSCRIBER. 

Table  6-3  summarizes  the  data  units  transferred  from  one  OTCIXS  II  subscriber  to  another 
OTCIXS  II  subscriber. 


Table  6-3 .  Subscriber  to  Subscriber  Data  Unit  Summary 


COMPONENT 

DATA  UNIT  NAME 

ID 

FIGURE 

Subscriber  Transmission  Unit  (STU) 

D 

6-3 

Network  Message 

- 

6-4 

Data  Link  Layer  Packet 

- 

6-5 
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BIT  POSITIONS 


B 

Y 

T 


E 

7  I  6 

5 

4  | 

3  2 

1  o 

0 

CID 

COPY 

RATS  TYPE 

1 

CTO 

COPY 

RATS  TYPE 

2 

CID  @5 

COPY  @  1 

RATS  TYPE  @  1 

3 

NCS  SID  (LSB) 

4 

NCS  SID  ILSB1 

5 

NCS  SID  (LSB)  @55 

6 

NAJ 

NCS  SID  (MSB) 

7 

N/U 

NCS  SID  (MSB1 

8 

NAJ 

NCS  SID  (MSB)  @  15 

9 

!  N/U 

HOURS 

A 

N/U 

MINUTES 

& 

N/U 

SECONDS 

c 

TIME  CHECKSUM 

D 

GRANTED  SID  (GSID)  (LSB) 

E 

GRANTED  SID  (GSID)  (LSB) 

F 

GRANTED  SID  (GSID)  (LSB)  @  55 

10 

N/U 

GRANTED  SID  (GSID)  (MSB) 

11 

N/U 

GRANTED  SID  (GSID)  (MSB) 

12 

NAJ 

GRANTED  SID  l 

(GSID)  (MSB)  @  15 

13 

XMITCT 

FLASH  SLOTS 

IMMEDIATE  SLOTS 

14 

xmitct 

FLASH  SLOTS 

IMMEDIATE  SLOTS 

15 

XMITCT  @1 

FLASH  SLOTS  @  2 

IMME 

iDIATE  SLOTS  @  5 

16 

MODE 

SB  STATUS 

HITS 

WINDOW  SIZE 

17 

MODE 

SB  STATUS 

HITS 

WINDOW  512k 

18 

MODE  @  1 

SB  STATUS  @  1 

HITS  @  1 

WINDOW  SIZE  @1 

Figure  6-1 .  Net  Control  Block  (NCB)  Transmission  Unit 
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BIT  POSITION 


B 

Y 

T 

E 


7  6 

5  4  3  2  1  0 

19 

STU  1  ACKNOWLEDGE  (LSB) 

1A 

N/U 

STU  1  ACKNOWLEDGE  (MSB) 

IB 

STU  2  ACKNOWLEDGE  (LSB) 

1C 

N/U 

STU  2  ACKNOWLEDGE  (MSB) 

ID 

STU  3  ACKNOWLEDGE  (LSB) 

IE 

N/U 

STU  3  ACKNOWLEDGE  (MSB) 

IF 

NCS  LAQ  SIZE 

20 

NCSLAQ 
(see  description) 

0 

o 

0 

N 

BYTE 

FIELD 

DESCRIPTION 

0 

RATS  TYPE 

Identifies  the  type  of  RATS  supported  in  this  net  cycle  as 

(bits  0-1) 

follows: 

0  -  Normal  RATS 

1  -  Initial  net  cycle  of  extended  RATS 

2  -  Intermediate  net  cycle  of  extended  RATS 

3  -  Final  net  cycle  of  extended  RATS 

0 

COPY 

Indicates  which  copy  of  the  NCB  has  been  received;  i.e.,  1 

(bits  2-3) 

is  the  first  transmission,  2  is  the  second  transmission.  Legal 
values  are  1  through  2. 

0 

CID 

Indicates  the  NCB  data  unit.  Value  is  always  hexadecimal 

(bits  4-7) 

B. 

1 

(bits  0-1) 

RATS  TYPE 

One's  complement  of  the  RATS  TYPE  field. 

1 

(bits  2-3) 

COPY 

One's  complement  of  the  COPY  field. 

Figure  6-1 .  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


1 

(bits  4-7) 

CBD 

One's  complement  of  the  CID  field. 

2 

(bits  0-1) 

RATS  TYPE  @  1 

Exclusive  OR  of  the  RATS  TYPE  field  with  1. 

2 

(bits  2-3) 

COPY  @  1 

Exclusive  OR  of  the  COPY  field  with  1. 

2 

(bits  4-7) 

CID  @  5 

Exclusive  OR  of  the  CID  field  with  5. 

3 

NCS  SID  (LSB) 

Contains  the  LSB  of  the  Net  Control  Station  (NCS)  ID.  Legal 
values  of  NCS  SID  are  0001  through  9999  (decimal). 

4 

NCS  SID  (LSB) 

One's  complement  of  the  NCS  SID  (LSB)  field 

5 

NCS  SID  (LSB) 
@55 

Exclusive  OR  of  the  NCS  SID  (LSB)  field  with  hexadecimal  55. 

6 

(bits  0-5) 

n 

NCS  SID  (MSB) 

Contains  the  MSB  of  the  Net  Control  Station  (NCS)  ID.  Legal 
values  of  NCS  SID  are  0001  through  9999  (decimal). 

/ 

(bits  0-5) 

NCS  SID  (MSB) 

One's  complement  of  the  NCS  SID  (MSB)  field. 

8 

(bits  0-5) 

NCS  SID  (MSB) 
@15 

Exclusive  OR  of  the  NCS  SID  (MSB)  field  with  hexadecimal 

15. 

9 

(bits  0-4) 

HOURS 

Hour  component  of  the  current  time  as  maintained  by  NCS. 

Legal  values  are  0  through  23  (decimal). 

A 

(bits  0-5) 

MINUTES 

Minute  component  of  the  current  time  as  maintained  by  NCS. 
Legal  values  are  0  through  59  (decimal). 

B 

(bits  0-5) 

SECONDS 

Second  component  of  the  current  time  as  maintained  by  NCS. 
Legal  values  are  0  through  59  (decimal). 

C 

TIME 

CHECKSUM 

The  least  significant  bits  of  the  one's  complement  of  the 
checksum  of  the  HOURS,  MINUTES,  and  SECONDS  fields. 
Compute  as: 

(((SECONDS  +  MINUTES)  x  2)  +  HOURS)  x  2 

Figure  6-1.  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BYTE  fc. 

FIELD 

DESCRIPTION 

*  D 

GSID  (LSB) 

Contains  the  LSB  of  the  SID  of  the  subscriber  that  has  been  granted 
the  next  STTS.  Values  of  0001  through  9999  identify  a  subscriber. 

A  value  of  zero  indicates  that  no  subscriber  has  been  assigned  the 
STTS. 

E 

GSID  (LSB) 

One's  complement  of  the  GSID  (LSB)  field. 

F 

GSID  (LSB)  @ 
55 

Exclusive  OR  of  the  GSID  (LSB)  field  with  hexadecimal  55. 

10 

Contains  the  MSB  of  the  SID  of  the  subscriber  that  has  been  granted 

(bits  0-5) 

GSID  (MSB) 

the  next  STTS.  Values  of 0001  through  9999  identify  a  subscriber. 

A  value  of  zero  indicates  that  no  subscriber  has  been  assigned  the 

ii 

STTS. 

(bits  0-5) 

GSID  (MSB) 

One's  complement  of  the  GSID  (MSB)  field. 

12 

bits  0-5) 

GSID  (MSB) 

Exclusive  OR  of  the  GSID  (MSB)  field  with  hexadecimal  15. 

@15 

13 

Indicates  the  number  of  Immediate  RSs  in  the  current  net  cycle. 

(bits  0-5) 

IMMEDIATE 

These  slots  follow  all  Flash  precedence  RSs  in  the  RATS.  This  field 

SLOTS 

is  ignored  except  when  the  RATS  TYPE  field  indicates  Normal 

RATS. 

13 

FLASH 

Indicates  the  number  of  Flash  precedence  RSs  in  the  RATS  of  the 

(bits  0-2) 

SLOTS 

current  net  cycle.  These  slots  precede  all  Immediate  precedence  RSs 
in  die  RATS.  This  field  is  ignored  except  when  the  RATS  TYPE 
field  indicates  Normal  RATS. 

13 

Indicates  the  number  of  times  the  subscriber  designated  by  the  GSID 

(bits  6-7) 

XMETCT 

field  is  to  transmit  a  STU  in  the  STTS.  Value  range  is  one  through 
three.  A  value  of  zero  is  illegal  and  shall  be  treated  as  one. 

14 

IMMEDIATE 

One's  complement  of  the  IMMEDIATE  SLOTS  field. 

(bits  0-2) 

SLOTS 

14 

(bits  3-5) 

FLASH 

SLOTS 

One’s  complement  of  the  FLASH  SLOTS  field. 

14 

(bits  6-7) 

XMITCT 

One's  complement  of  the  XMET  CT  field. 

Figure  6-1.  Net  Control  Block  (NCB^Transmission  Unit  (cont.) 


BYTE 


FIELD 


DESCRIPTION 


15 

(bits  0-2) 

IMMEDIATE 
SLOTS  @  5 

Exclusive  OR  of  the  IMMEDIATE  SLOTS  field  with 
hexadecimal  5. 

15 

(bits  3-5) 

FLASH 
SLOTS  @  2 

Exclusive  OR  of  the  FLASH  SLOTS  field  with  hexadecimal  2. 

15 

(bits  6-7) 

XMITCT@ 

1 

Exclusive  OR  of  the  XMIT  CT  field  with  1. 

16 

(bits  0-1) 

WINDOW 

SIZE 

Identifies  the  size  of  the  window,  in  net  cycles,  to  be  used  by 
network  subscribers  in  predicting  their  network  service 
requirements.  Legal  values  are  as  follows: 

0  - 12  net  cycles 

1- 16  net  cycles 

2- 20  net  cycles 

3- 24  net  cycles 

16 

(bits  2-3) 

HITS 

Identifies  the  minimum  number  of  net  cycles,  within  the 
window  specified  by  the  WINDOW  SIZE  field,  in  which  a  net 
member  must  receive  at  least  one  message  for  transmission  in 
order  to  predict  a  network  service  requirement.  Legal  values  are 
as  follows: 

0  -  2  net  cycles 

1  -  3  net  cycles 

2  -  4  net  cycles 

3  -  5  net  cycles 

16 

(bits  4-5) 

SB  STATUS 

Indicates  the  scheduled  broadcasting  status  during  this  net 
cycles  as  follows: 

0  -  Scheduled  broadcast  activity  this  cycle 

1  -  Scheduled  broadcast  activity  for  this  cycle  delayed  by  Flash 

transmission 

2  -  Scheduled  broadcast  activity  for  this  cycle  preempted 

3  -  No  scheduled  broadcast  activity  this  cycle 

16 

(bits  6-7) 

MODE 

Identifies  the  type  of  service  provided  during  this  net  cycle  as 
follows: 

0  -  Nonscheduled  transmission  of  Flash  precedence  STU 

1  -  Nonscheduled  transmission  of  Immediate  precedence  STU 

2  -  Scheduled  broadcast  STU  transmission 

3  -  No  STU  transmission 

Figure  6-1 .  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BYTE 

FIELD 

DESCRIPTION 

17 

(bits  0-1) 

WINDOW 

SIZE 

One's  complement  of  the  WINDOW  SIZE  field. 

17 

(bits  2-3) 

HITS 

One's  complement  of  the  HITS  field. 

17 

(bits  4-5) 

SB  STATUS 
@1 

One's  complement  of  the  SB  STATUS  field. 

17 

(bits  6-7) 

MODE 

One's  complement  of  the  MODE  field. 

18 

(bits  0-1) 

WINDOW 
SIZE  @  1 

Exclusive  OR  of  the  WINDOW  SIZE  field  with  1. 

18 

(bits  2-3) 

HITS  @  1 

Exclusive  OR  of  the  HITS  field  with  1 . 

18 

(bits  4-5) 

SB  STATUS 
@1 

Exclusive  OR  of  the  SB  STATUS  field  with  1. 

18 

(bits  6-7) 

MODE  @  1 

Exclusive  OR  of  the  MODE  field  with  1. 

19 

STU  1 

ACKNOWLE 
DGE  (LSB) 

Contains  the  LSB  of  the  SID  of  the  subscriber  that  transmitted 
an  STU  one  net  cycle  prior  to  this  one.  Indicates  that  NCS 
received  the  STU  sent  by  that  subscriber.  Values  of  000 1 
through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged.  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged. 

1A 

(bits  0-5) 

STU  1 

ACKNOWLE 
DGE  (MSB) 

Contains  the  MSB  of  the  SID  of  the  subscriber  that  transmitted 
an  STU  one  net  cycle  prior  to  this  one.  Indicates  that  NCS 
received  the  STU  sent  by  that  subscriber.  Values  of  0001 
through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged.  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged. 

IB 

STU  2 

ACKNOWLE 
DGE  (LSB) 

Contains  the  LSB  of  the  SID  of  the  subscriber  that  transmitted 
an  STU  two  net  cycles  prior  to  this  one.  Indicates  that  NCS 
received  the  STU  sent  by  that  subscriber.  Values  of 0001 
through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged.  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged. 

Figure  6-1.  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


1C  STU  2  Contains  the  MSB  of  the  SID  of  the  subscriber  that  transmitted 

(bits  0-5)  ACKNOWLE  an  STU  two  net  cycles  prior  to  this  one.  Indicates  that  NCS 

DGE  (MSB)  received  the  STU  sent  by  that  subscriber.  Values  of  0001 

through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged 

ID  STU  3  Contains  the  LSBofthe  SID  of  the  subscriber  that  transmitted 

ACKNOWLE  an  STU  three  net  cycles  prior  to  this  one.  Indicates  that  NCS 
DGE  (LSB)  received  the  STU  sent  by  that  subscriber.  Values  of  0001 

through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged.  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged 

IE  STU  3  Contains  the  MSB  of  the  SID  of  the  subscriber  that  transmitted 

(bits  0-5)  ACKNOWLE  an  STU  three  net  cycles  prior  to  this  one.  Indicates  that  NCS 

DGE  (MSB)  received  the  STU  sent  by  that  subscriber.  Values  of 0001 

through  9999  (decimal)  indicate  the  SID  of  the  subscriber  being 
acknowledged.  A  value  of  zero  indicates  that  no  subscriber  is 
being  acknowledged 


NCSLAQ 

SIZE 


NCSLAQ 


Indicates  the  number  of  subscribers  that  are  awaiting 
assignment  of  link  time  for  STU  transmissions;  that  is,  the 
number  of  entries  in  the  LAQ.  The  queue  can  contain  up  to  2 1 
(decimal)  entries. 

The  SIDs  of  the  subscribers  currently  awaiting  assignment  of 
link  time  for  STU  transmissions.  The  length  of  this  queue  is 
given  by  the  contents  of  the  NCS  LAQ  SIZE  field  Each  entry 
in  the  NCS  LAQ  consists  of  three  bytes  defined  as  follows: 


.BIT  position: 


1  I  0 


m+2  I  XMITCT 


TRANSMIT  MINUTE 


Figure  6-1 .  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BYTE 

FIELD 

DESCRIPTION 

20-K  (cont.) 

NCS LAQ 
(cont.) 

Where: 

SID  (LSB)  is  the  LSB  of  the  subscriber  SID 

SID  (MSB)  is  the  MSB  of  the  subscriber  SID.  SIDs  000 1 ' 
through  9999  (decimal)  identify  network  subscribers. 

MODE  identifies  the  type  of  entry  as  follows: 

0  -  Nonscheduled  transmission  of  Flash  precedence 

STU 

1  -  Nonscheduled  transmission  of  Immediate 

precedence  STU 

2  -  Scheduled  broadcast  STU  transmission 

3  -  Predicted  nonscheduled  transmission  of  Immediate 

precedence  STU. 

TRANSMIT  MINUTE  is  the  minute  within  the  hour  at  which 
scheduled  broadcast  by  this  subscriber  is  to  commence.  Field  is 
not  interpreted  when  the  MODE  field  of  the  queue  entry 
indicates  a  nonscheduled  broadcast. 

XMIT  CT  is  the  number  of  times  the  subscriber  has  requested 
its  STU  be  broadcast.  Range  of  values  is  one  through  three.  A 
value  of  zero  is  illegal  and  shall  be  treated  as  one. 

Figure  6-1.  Net  Control  Block  (NCB)  Transmission  Unit  (cont.) 
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BIT  POSITIONS 


B 

Y 

T 


JUt 

7  6 

5  4 

3  2 

1  0 

0 

CID 

COPY 

N/U 

1 

ODD 

COPY 

N/U 

2 

CID  @5 

COPY  @  1 

N/U 

3 

SID  (LSB) 

4 

SID  (LSB) 

5 

SID  (LSB)  @55 

6 

MODE 

SID  (MSB) 

7 

MODE 

SID  (MSB) 

8 

MODE  @  1 

SID  (MSB)  @  15 

9 

XMTTCT 

TRANSMIT  MINUTE 

A 

XMTTCT 

TRANSMIT  MINUTE 

B 

XMIT  CT  @  1 

TRANSMIT  MINUTE  @  15 

C 

RETRY  COUNT 

D 

RETRY  COUNT 

E 

RETRY  COUNT  @  55 

BYTE 

FIELD 

DESCRIPTION 

0 

(bits  2-3) 

0 

(bits  4-7) 

COPY 

Indicates  which  copy  of  the  RR  has  been  received;  i.e.,  1 
is  the  first  transmission,  2  is  the  second  transmission. 

Legal  values  are  1  through  2. 

CID 

Indicates  the  RR  data  unit.  Value  is  always  hexadecimal 

C. 

1 

(bits  2-3) 

COPY 

One's  complement  of  the  COPY  field. 

1 

(bits  4-7) 

CID 

One's  complement  of  the  CID  field. 

Figure  6-2.  Reservation  Request  (RR)  Transmission  Unit 
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BYTE 


FIELD 
COPY  m  1 


_ DESCRIPTION 

Exclusive  OR  of  the  COPY  field  with  1. 


2 

(bits  2-3) 
2 

(bits  4-7) 
3 


4 


5 

6 

(bits  0-5) 


6 

(bits  6-7) 


7 

(bits  0-5) 

7 

(bits  6-7) 

8 

(bits  0-5) 
8 

(bits  6-7) 
9 

(bits  0-5) 


SID  (LSB) 
SID  (LSB)  @  55 
SID  (MSB) 


MODE 


SID  (MSB) 

MODE 

SID  (MSB)  @  15 
MODE  @  1 

TRANSMIT  MINUTE 


Exclusive  OR  of  the  CID  field  with  5. 


Contains  the  LSB  of  the  SID  of  the  network  subscriber 
that  is  requesting  service.  Legal  values  are  000 1 
through  9999  (decimal). 


One's  complement  of  the  SID  (LSB)  field. 


Exclusive  OR  of  the  SID  (LSB)  field  with  hexadecimal 
55. 

Contains  the  MSB  of  the  SID  of  the  network  subscriber 
that  is  requesting  service.  Legal  values  are  0001 
through  9999  (decimal). 

Indicates  the  type  of  service  being  requested  as  follows: 

0  -  Nonscheduled  transmission  of  Flash  precedence 
STU 

1  -  Nonscheduled  transmission  of  Immediate 

precedence  STU 

2  -  Scheduled  broadcast  transmission  of  STU 
3-N/U 


One’s  complement  of  the  SID  (MSB)  field. 


One’s  complement  of  the  MODE  field. 


Exclusive  OR  of  the  SID  (MSB)  field  with  hexadecimal 
15. 

Exclusive  OR  of  the  MODE  field  with  1. 


Indicates  the  minute  within  the  hour  at  which  a 
scheduled  broadcast  is  to  occur.  Field  is  not  interpreted 
when  the  MODE  field  indicates  a  nonscheduled 
broadcast. 


Figure  6-2.  Reservation  Request  (RR)  Transmission  Unit  (cont.) 
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BYTE 


FELD 


DESCRIPTION 


9 

(bits  6-7) 


XMTT  CT 


Indicates  the  requested  number  of  times  that  the  STU  is 
to  be  broadcast.  Range  of  legal  values  is  one  through 
three.  A  value  of  zero  is  illegal  and  shall  be  treated  as 
one. 


A 

(bits  0-5) 
A 

(bits  6-7) 


TRANSMIT 

MINUTE 


XMITCT 


One's  complement  of  the  TRANSMIT  MINUTE  field. 
One's  complement  of  the  XMIT  CT  field. 


B 

(bits  0-5) 


TRANSMIT 
MINUTE  @15 


Exclusive  OR  of  the  TRANSMIT  MINUTE  field  with 
hexadecimal  15. 


B 

(bits  6-7) 


XMIT  CT  @  1 


Exclusive  OR  of  the  XMIT  CT  field  with  1. 


C 


D 


RETRY  COUNT 


Indicates  the  number  of  times  the  subscriber  attempted 
net  entry,  prior  to  acknowledgement  of  the  request  in  the 


NCB. 


RETRY  COUNT 


One's  complement  of  the  RETRY  COUNT  field. 


E 


RETRY  COUNT 
55 


Exclusive  OR  of  the  RETRY  COUNT  field  with 
hexadecimal  55. 


Figure  6-2.  Reservation  Request  (RR)  Transmission  Unit  (cont.) 
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B 

Y 

T 

E 

7 

6 

5 

BIT  I 

4 

>OSITI 

3 

ONS 

2 

1 

0 

0 

CID 

COPY 

PREC 

RESV 

1 

CID 

COPY 

PREC 

RESV 

2 

CID  @  5 

COPY  @  1 

PREC 

RESV  @  1 

3 

SID  (LSB) 

4 

SID  (LSB) 

5 

SID  (LSB)  @  55 

6 

MODE 

SID  (MSB) 

7 

MODE 

SID  (MSB) 

8 

MODE  @  1 

SID  (MSB)  @  15 

9 

XMITCT 

TRANSMIT  MINUTE 

A 

XMITCT 

TRANSMIT  MINUTE 

B 

XMITCT  @1 

TRANSMIT  MINUTE  @  15 

C 

MORE 

0 

0 

0 

0 

0 

0 

0 

D 

MORE 

0 

0 

0 

0 

0 

0 

0 

E 

MORE 

0 

0 

0 

0 

0 

0 

0 

F 

0 

0 

0 

N 

MESSAGE  POINTER  BLOCK 

(see  description) 

Ml 

0 

o 

0 

M2-1 

NETWORK  MESSAGE  1 

Figure  6-3.  Subscriber  Transmission  Unit 
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BIT  POSITIONS 


B 

Y 

T 

E 


M2 


o 

o 

0 


Mn-1 


o 

o 


Mn 


o 

o 

0 


Mz 


NETWORK  MESSAGE  n 


BYTE 

FIELD 

DESCRIPTION 

0 

RESV 

Indicates  the  presence  or  absence  of  a  "piggy-back" 

(bitO) 

reservation  request  in  this  STU.  A  value  of  one  indicates 
a  ”piggy-back"  reservation  request  is  present;  a  value  of 
zero  indicates  no  such  request  is  present. 

0 

PREC 

Indicates  the  precedence  of  the  STU.  A  value  of  zero 

(bill) 

indicates  an  Immediate  precedence  STU.  A  value  of  one 
indicates  a  Flash  precedence  STU. 

0 

(bits  2-3) 

COPY 

Indicates  which  copy  of  the  STU  has  been  received;  i.e.,  1 
is  the  first  transmission,  2  is  the  second  transmission,  etc. 

Legal  values  are  1  through  3. 

0 

CID 

Indicates  an  STU.  Value  is  always  hexadecimal  D. 

(bits  4-7) 

1 

RESV 

One’s  complement  of  the  RESV  field 

(bitO) 

1 

PREC 

One’s  complement  of  the  PREC  field. 

(bill) 

Figure  6-3.  Subscriber  Transmission  Unit  (cont.) 


129 


BYTE 


FIELD 


DESCRIPTION 


1 

(bits  2-3) 
1 

(bits  4-7) 
2 

(bitO) 

2 

(bit  1) 

2 

(bits  2-3) 
2 

(bits  4-7) 


3 


4 


5 


6 

(bits  0-5) 


6 

(bits  6-7) 


COPY 

One’s  complement  of  the  COPY  field. 

CDD 

One's  complement  of  the  CID  field 

RESV  @  1 

Exclusive  OR  of  the  RESV  field  with  1. 

PREC 

Duplicate  of  byte  0  (bit  1). 

COPY  @  1 

Exclusive  OR  of  the  COPY  field  with  1. 

CID  @  5 

Exclusive  OR  of  the  CID  field  with  5. 

SID  (LSB) 

Contains  the  LSB  of  the  SID  of  the  network  subscriber 
originating  the  transmission.  Legal  values  are  0001 
through  9999  (decimal). 

SID  (LSB) 

One's  complement  of  the  SID  (LSB)  field 

SID  (LSB)  @  55 

Exclusive  OR  of  the  SID  (LSB)  field  with  hexadecimal 

55. 

SID  (MSB) 

Contains  the  MSB  of  the  SID  of  the  network  subscriber 
originating  the  transmission.  Legal  values  are  0001 
through  9999  (decimal). 

MODE 

Indicates  the  type  of  service  request  that  is  "piggy¬ 
backed"  to  this  STU  as  follows: 

0  -  Nonscheduled  transmission  of  Flash 
precedence  STU  required 

1  -  Nonscheduled  transmission  of  Immediate 

precedence  STU  required 

2  -  Scheduled  broadcast  transmission  of  STU 

required 

3  -  Nonscheduled  transmission  of  Immediate  precedence 

STU  predicted 

This  field  is  not  interpreted  when  the  RESV  field 
indicates  that  no  "piggy-back"  reservation  request  is 
present. 

Figure  6-3 .  Subscriber  Transmission  Unit  (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


7 

(bits  0-5) 

SID  (MSB) 

One’s  complement  of  the  SID  (MSB)  field 

7 

(bits  6-7) 

MODE 

One's  complement  of  the  MODE  field 

8 

(bits  0-5) 

SID  (MSB)  @  15 

Exclusive  OR  of  the  SID  (MSB)  field  with  hexadecimal 

15. 

8 

(bits  6-7) 

MODE  @  1 

Exclusive  OR  of  the  MODE  field  with  1 . 

9 

(bits  0-5) 

TRANSMIT 

MINUTE 

Indicates  the  minute  within  the  hour  at  which  a  scheduled 
broadcast  is  to  occur.  This  field  is  interpreted  only  when 
the  RESV  field  indicate  that  a  "piggy-back”  reservation 
request  is  present  and  the  MODE  field  indicates  that 
Scheduled  broadcast  transmission  of  a  STU  is  required 

9 

(bits  6-7) 

XMtTCT 

Indicates  the  requested  number  of  times  the  STU  in  the 
"piggy-back"  reservation  request  is  to  be  broadcast. 

Range  of  legal  values  is  one  through  three.  A  value  of 
zero  is  illegal  and  shall  be  treated  as  one. 

A 

(bits  0-5) 

TRANSMIT 

MINUTE 

One's  complement  of  the  TRANSMIT  MINUTE  field. 

A 

(bits  6-7) 

XMITCT 

One's  complement  of  the  XMIT  CT  field 

B 

(bits  0-5) 

TRANSMIT 
MINUTE  @  15 

Exclusive  OR  of  the  TRANSMIT  MINUTE  field  with 
hexadecimal  15. 

B 

(bits  6-7) 

C 

(bit  7) 

XMIT  CT  @  1 

MORE 

Exclusive  OR  of  the  XMIT  CT  field  with  1. 

Indicates  if  additional  service  is  required  for  STU 
transmission  on  the  current  broadcast  schedule.  A  value 
of  one  indicates  service  is  required;  a  value  of  zero 
indicates  no  such  requirement  exists. 

D 

(bit  7) 

MORE 

One's  complement  of  the  MORE  field 

Figure  6-3 .  Subscriber  Transmission  Unit  (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


E 

(bit  7) 


MORE 


Duplicate  of  byte  C  (bit  7). 


F-N 


MESSAGE 
POINTER  BLOCK 


Indicates  the  location  of  the  start  of  the  messages  in  the 
STU.  The  block  is  formatted  as  follows: 


B 


Where: 

MESSAGE  COUNT  is  the  number  of  network  messages 
present  in  the  STU. 


POINTER  1  (LSB)  is  the  LSB  of  the  location  of  the  start 
of  NETWORK  MESSAGE  1  relative  to  the  start  of  the 
MESSAGE  POINTER  BLOCK. 

POINTER  1(MSB)  is  the  MSB  of  the  location  of  the  start 
of  NETWORK  MESSAGE  1  relative  to  the  start  of  the 
MESSAGE  POINTER  BLOCK. 


Figure  6-3.  Subscriber  Transmission  Unit  (cont  .) 
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BYTE 


FIELD 


DESCRIPTION 


F-N  (cont.) 


MESSAGE 
POINTER  BLOCK 
(cont.) 


POINTER  n  (LSB)  is  the  LSB  of  the  location  of  the  start 
of  NETWORK  MESSAGE  n  relative  to  the  start  of  the 
MESSAGE  POINTER  BLOCK. 


Ml  -  (M2-1) 


POINTER  n  (MSB)  is  the  LSB  of  the  check  sequence 
calculated  over  the  MESSAGE  COUNT  field  and  each  of 
the  MESSAGE  POINTER  fields.  The  algorithm  used  to 
calculate  the  check  sequence  is  defined  in  appendix  B. 

PCS  (LSB)  is  the  LSB  of  the  check  sequence  calculated 
over  the  MESSAGE  COUNT  field  and  each  of  the 
MESSAGE  POINTER  fields.  The  algorithm  used  to 
calculate  the  check  sequence  is  defined  in  appendix  B. 

PCS  (MSB)  is  the  MSB  of  the  check  sequence  calculated 
over  the  MESSAGE  COUNT  field  and  each  of  the 
MESSAGE  POINTER  fields.  The  algorithm  used  to 
calculate  the  check  sequence  is  defined  in  appendix  B. 

NETWORK  Contains  network  message  number  1. 

MESSAGE  1 


Mn  -Mz 


NETWORK 
MESSAGE  n 


Contains  network  message  number  n. 


Figure  6-3.  Subscriber  Transmission  Unit  (cont.) 
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BIT  POSITIONS 


B 

Y 

T 

E 


7 

6 

5 

4  3 

2 

1 

0 

0 

BSN  (LSB) 

1 

BSN  (MSB) 

2 

0 

0 

0 

TRANSPORT  MESSAGE 

N 

BYTE 

FIELD 

DESCRIPTION 

0,1 

BSN 

Indicates  the  Broadcast  Sequence  Number  (BSN)  assigned 

- 

to  the  TRANSPORT  MESSAGE.  Legal  values  are  0001- 

9999. 

2-N 

TRANSPORT 

Contains  the  Transport  Layer  messasge  as  specified  in  the 

MESSAGE 

TADIXS  IDS,  Volume  I.  (Should  be  renamed  to 

OTCIXS/T ADIXS  Transport  Layer  IDS). 

Figure  6-4.  Network  Message 
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B 

Y 

T 


BIT  POSITIONS 


7 

6 

5 

4  3 

2 

1 

0 

0 

END 

COUNT 

1 

0 

0 

INFORMATION 

0 

61 

62 

CRC  (LSB) 

63 

CRC  (MSB) 

BYTE 

FIELD 

DESCRIPTION 

0 

(bits  0-6) 

COUNT 

Indicates  the  number  of  bytes  in  the  INFORMATION  field 
of  the  packet.  With  the  exception  of  the  final  packet  of  a 
multipacket  sequence,  the  value  of  this  field  shall  be  97 
(decimal)  bytes.  In  the  final  packet  of  a  multipacket 
sequence,  legal  values  for  this  field  are  1-97  (decimal) 
bytes. 

0 

END 

Indicates  if  this  packet  is  the  final  packet  of  a  multipacket 
sequence.  Value  is  1  if  this  is  the  final  packet;  value  is  0  if 
this  is  not  the  final  packet. 

1-61 

INFORMATION 

Consists  of  a  part  or  all  of  a  network  message.  The  length 
of  this  field  is  indicated  by  the  contents  of  the  COUNT 
field.  The  INFORMATION  field  in  all  packets  except  the 
last  of  a  multipacket  sequence  shall  be  97  (decimal)  bytes 
in  length.  The  length  of  the  INFORMATION  field  in 
final  packet  of  a  multipacket  sequence  is  1-97  (decimal) 
bytes. 

62 

CRC  (LSB) 

Contains  the  LSB  of  the  CRC.  Calculated  over  the 

COUNT,  END,  and  INFORMATION  fields.  The  CRC  is 
calculated  using  the  polynomial  algorithm  contained  in 
appendix  B. 

63 

CRC  (MSB) 

Contains  the  MSB  of  the  CRC.  Calculated  over  the 
COUNT,  END,  and  INFORMATION  fields.  The  CRC  is 
calculated  using  the  polynomial  algorithm  contained  in 
appendix  B. 

Figure  6-5.  Data  Link  Layer  Packet  Format 
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APPENDIX  A 


LIST  OF  ACRONYMS  and  ABBREVIATIONS 


Acronym 

Definition 

ADCCP 

Advanced  Data  Communications  Control  Procedure 

Ascn 

American  Standard  Code  for  Information  Interchange 

BCS 

Block  Check  Sequence 

bps 

bits  per  second 

BPSK 

Bi-phase  Phase  Shift  Keyed 

BSN 

Broadcast  Sequence  Number 

CCITT 

International  Telegraph  and  Telephone  Consultative  Committee 

CCS 

Combat  Control  System 

Cl 

Control  Indicator 

CID 

Component  Identification 

CMSA 

Cruise  Missile  Support  Activity 

COMASWFOR 

Commander,  Antisubmarine  Warfare  Forces 

COMSUBGRU 

Commander,  Submarine  Group 

COMSUBLANT 

Commander,  Submarine  Forces  Atlantic 

COMSUBPAC 

Commander,  Submarine  Forces  Pacific 

CONUS 

Continental  United  States 

CRA 

Contention  Resolution  Algorithm 

CRC 

Cyclic  Redundancy  Check 

CTS 

Control  Time  Slot 
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Acronym 

DAMA 

DART 

DoD 

EASTPAC 

EOC 

ERCT 

ETCT 

FCDSSA 

FCFS 

FDDS 

FIFO 

FLTSA 

FOSIC 

FOSIF 

GRD 

GSBD 

ID 

EDS 

IF 

10 

ISO 

K/VDT 


Definition 

Demand  Assigned  Multiple  Access 
Dynamically  Adaptive  Receiver/Transmitter 
Department  of  Defense 
Eastern  Pacific 
End  of  Cycle 

External  Receive  Ciphered  Text 

External  Transmit  Ciphered  Text 

Fleet  Combat  Direction  Systems  Support  Activity 

First-Come,  First-Served 

Flag  Data  Display  System 

First-in,  First-out 

Fleet  Satellite 

Fleet  Ocean  Surveillance  Information  Center 
Fleet  Ocean  Surveillance  Information  Facility 
Guard 

Granted  Subscriber  Identification 
Identification 

Interface  Design  Specification 
Intermediate  Frequency 
Indian  Ocean 

International  Standards  Organization 
Keyboard/Video  Display  Terminal 
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Arrnnym 

Definition 

LANT 

Atlantic 

LAQ 

Link  Access  Queue 

LEASAT 

Leased  Satellite 

LSB 

Least  Significant  Byte 

MDDS 

Mission  Data  Distribution  System 

MED 

Mediterranean 

MIAR 

Message  Indicate  Alarm  Reset 

MSB 

Most  Significant  Byte 

NCB 

Net  Control  Block 

NCS 

Network  Control  Station 

NCTAMS 

Naval  Computer  and  Telecommunications  Area  Master  Station 

NCTS 

Naval  Computer  Telecommunications  Station 

NDF 

Network  Description  File 

NSDL 

Network  Simulation  Description  Language 

N/U 

Not  Used 

OSIS 

Ocean  Surveillance  Information  System 

otcixs 

Officer  in  Tactical  Command  Information  Exchange  Subsystem 

OTH-T 

Over-the-Horizon  Targeting 

OTH/DCT 

Over-the-Horizon  Detection,  Classification  and  Targeting 

PAC 

Pacific 

PCS 

Pointer  Check  Sequence 

PIO 

Parallel  Input/Output 
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Acronym 

PREC 

RADCON 

RATS 

RDO 

RD1 

RED-AI 

REMCON 

RESV 

rf 

RP-STBYR 

RR 

RRTU 

RS 

RX-DPT 

SAT 

SATCOM 

SATS 

SB  STATUS 
SID 

SIGACQ 

SIU 

SPAWARSYSCOM 


Definition 

Precedence 

Radio  Controller 

Random  Access  Time  Slot 

Red  Receive  Data 

Crypto  Receive  Data 

Red  Alarm  Indicate 

Remote  Controller 

Reservation 

Radio  Frequency 

Remote  Standby  Red 

Reservation  Request 

Reservation  Request  Transmission  Unit 

Request  Slot 

Receive  Digital  Plain  Text 
Satellite 

Satellite  Communications 
Single  Access  Time  Slot 
Scheduled  Broadcast  Status 
Subscriber  Identification 
Signal  Acquired 
Sensor  Interface  Unit 

Space  and  Naval  Warfare  Systems  Command 
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Arrnnym 

Definition 

SSIXS 

Submarine  Satellite  Information  Exchange  Subsystem 

STM 

Slot  Time  Mark 

STT 

Shore  Targeting  Terminal 

STTS 

Subscriber  Transmission  Time  Slot 

STU 

Subscriber  Transmission  Unit 

SYNC-CMD-TX 

Synchronize  Command  Transmit 

TADIXS  A 

Tactical  Data  Information  Exchange  Subsystem  A 

TBD 

To  Be  Determined 

TOO 

Crypto  Transmit  Data 

TO1 

Red  Transmit  Data 

TODS 

Tactical  Data  Display  System 

TOMA 

Time  Division  Multiple  Access 

TOP 

Tactical  Data  Processor 

TOPCON 

Tactical  Data  Processor  Controller 

TGF 

TADIXS  Gateway  Facility 

TGP 

TADIXS  Gateway  Processor 

TTY 

Teletype 

TU 

Transmission  Unit 

TWCS 

Tomahawk  Weapons  Control  System 

TX-DPT 

Transmit  Digital  Plain  Text 

UHF 

Ultrahigh  Frequency 

USCINCLANT 

United  States  Commander-in-Chief,  Atlantic 
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Acronym 

USCINCPAC 
WESTPAC 
WPC 
XMIT  CT 


Definition 

United  States  Commander-in-Chief,  Pacific 
Western  Pacific 
Washington  Planning  Center 
Transmit  Count 
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APPENDIX  B 


CYCLIC  REDUNDANCY  CHECK  SEQUENCE  GENERATION 


A.  GENERAL.  This  appendix  defines  the  Cyclic  Redundancy  Check  (CRC)  algorithm  used 
by  the  data  units  of  the  OTCIXS  n  network.  The  generator  polynomial  used  in  the  CRC 
calculation  is  the  polynomial  defined  by  the  International  Telegraph  and  Telephone 
Consultative  Committee  (CCITT)  Recommendation  V.41  and  used  in  ANSI  Standard  X3.66 
for  Advanced  Data  Communication  Control  Procedures  (ADCCP).  This  generator 
polynomial  is:  G(X)  =  X16  +  X12  +  Xs  +  1 . 

B.  CRC  GENERATION  ALGORITHM.  The  software  algorithm  which  realizes  this 
process  is  shown  in  Figure  B-l .  For  convenience  of  implementation,  and  to  permit  high  speed 
generation  of  the  CRC,  the  algorithm  has  been  designed  to  process  one  8-bit  byte  at  a  time. 
Figure  B-2  contains  a  listing  of  the  algorithm  as  programmed  for  an  8080  microprocessor. 
Table  B-l  provides  samples  from  the  CRC  generation  algorithm. 


Table  B-l .  Sample  Inputs/Outputs  For  CRC  Generator 


INPUT 

(Hexadecima 

0 

RESULT 

(Hexadecimal) 

HI  BYTE 

LOBYTE 

ACCUMULATOR 

HI  BYTE 

LOBYTE 

FF 

FF 

01 

FI 

D1 

FF 

FF 

00 

El 

F0 

FF 

FF 

80 

70 

78 

00 

00 

01 

10 

21 

00 

00 

80 

91 

88 

55 

55 

01 

4F 

71 

55 

55 

80 

CE 

D8 

55 

55 

55 

55 

00 

AA 

AA 

AA 

AA 

00 
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OPERATION 


STEP 


1 

A  =  Incoming  Byte 

2 

I  =  CRCHI  XOR.  A 

3 

A  =  I  .RS.  4 

4 

A  =  I .  XOR.  A 

5 

I  =  A 

6 

A  =  A  .LS.  4 

7 

A  =  A  . XOR.  CRCLO 

8 

J  =  A 

9 

A  =  I 

10 

A  =  A  .RS.  3 

11 

A  =  A  XOR.  J 

12 

CRCHI  =  A 

13 

A  =  I 

14 

A  =  A  .LS.  5 

15 

A  =  A. XOR.  I 

16 

CRCLO  =  A 

Where: 

A  is  an  8-bit  accumulator  register 
I  and  J  are  8-bit  scratch  pad  registers 
CRCHI  is  the  high  order  8  bits  of  the  CRC 
CRCLO  is  the  low  order  8  bits  of  the  CRC 
.XOR.  is  an  8-bit  Exclusive  OR  operation 
.RS.  is  a  right-shift 
.LS.  is  a  left-shift 

Note:  Right-  and  left-shifts  "pull  zeros,"  e.g.,  ABCDEFGH  right-shifted  3  would 
produce  000ABCDE. 

Initial  value  of  CRCHI  and  CRCLO  is  zero  before  applying  this  algorithm  to  data 
bytes  in  the  data  frame. 


Figure  B-l.  CRC  Generator  Algorithm 
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CRC  -  ROUTINE  TO  CALCULATE  THE  CRC  FOR  8080  MICROPROCESSOR. 

ON  ENTRY,  H  = 

MSB  OF  CRC,  L  =  LSB  OF  CRC,  A  =  NEW  BYTE; 

RESULT  IS  H  =  MSB  OF  NEW  CRC,  L  =  LSB  OF  NEW  CRC. 

CRC:  XRA  H 

^XCLUSIVE-OR  CRC  MSB  AND  ACCUM 

MOV  D,  A 

;STORE  IN  SCRATCHPAD 

RRC 

;SHIFT  ACCUM  RIGHT  4 

RRC 

RRC 

RRC 

ANIOFH 

;ACCUMULATOR  NOW  HAS  0000IJKL 

XRAD 

;EXCLUSIVE-OR  SCRATCHPAD  AND  ACCUM 

MOV  D,  A 

RESULT  IS  DKLMNOP,  SAVE  IN  SCRATCHPAD 

RLC 

;SHIFT  ACCUM  LEFT  4 

RLC 

RLC 

RLC 

ANI0F0H 

;ACCUM  NOW  HAS  MNOPOOOO 

XRAL 

;XOR  ACCUM  AND  LSB  OF  CRC 

MOVH,A 

;PUT  RESULT  IN  MSB  OF  CRC  TEMPORARILY 

MOV  A,D 

;BRING  BACK  IJKLMNOP  TO  ACCUM 

RRC 

;  SHIFT  ACCUM  RIGHT  3 

RRC 

RRC 

ANI1FH 

;ACCUM  NOW  HAS  000IJKLM 

XRAH 

;XOR  MSB  OF  CRC  AND  ACCUM 

MOVH,A 

;STORE  RESULT  AS  NEW  CRC  MSB 

MOV  A,D 

;BRING  BACK  IJKLMNOP  TO  ACCUM 

RLC 

;SHEFT  ACCUM  LEFT  5 

RLC 

RLC 

RLC 

RLC 

ANI0E0H 

;ACCUM  NOW  HAS  NOPOOOOO 

XRAD 

;XOR  SCRATCHPAD  AND  ACCUM 

MOV  L,  A 

RESULT  IS  NEW  CRC  LSB 

RET 

;EXIT  SUBROUTINE 

Figure  B-2.  8080  Listing  of  CRC  Generator 
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APPENDIX  C  Section  Cl 


OTCIXS II  SIMULATION  PREFORMANCE  RESULTS 

A.  PURPOSE. 

The  Officer  in  Tactical  Command  Information  Exchange  Subsystem  (OTCIXS)  is 
an  existing  subsystem  of  the  Navy  Ultrahigh  Frequency  (UHF)  Satellite  Communications 
(UHF  SATCOM)  System  that  provides  beyond  line-of-sight  automatic  exchange  of 
tactical  messages  between  ships,  submarines  and  shore  facilities.  Subscribers  may 
exchange  computer-to-computer  formatted  data  (datalink)  messages  or  teletype  messages 
via  the  OTCIXS  network.  The  OTCIXS  network  operates  on  a  demand  assign  basis  so 
that  when  a  subscriber  needs  to  transmit  data,  access  to  the  network  can  be  gained 
quickly.  The  OTCIXS  network  also  provides  for  priority  preemption  so  that  subscribers 
with  higher  priority  data  can  gain  control  of  the  network  by  interrupting  the  normal 
transmission  of  lower  priority  data.  The  current  OTCIXS  network  functions  well  in  the 
current  mode;  that  is,  without  the  use  of  multiplexing  equipment.  However,  there  is  a 
limited  ability  to  support  all  of  the  network  subsystems  that  exist  today  with  the  limited 
hardware  and  satellite  resources  available.  The  increasing  requirements  for  satellite 
communications  links  and  the  limited  number  of  available  satellite  channels  and 
transmit/receive  equipment  have  led  to  the  need  for  sharing  available  resources.  This  can 
be  accomplished  only  by  limiting  the  number  of  networks  supported  by  a  subscriber  or  by 
using  multiplexing  equipment. 

Early  analysis  indicates  that  the  current  OTCIXS  network  will  not  operate 
efficiently  using  the  TD-1271  B/U  Demand  Assigned  Multiple  Access  (DAMA) 
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multiplexing  equipment.  This  has  necessitated  the  development  of  a  proposed  a  new 
protocol  for  OTCIXS  that  will  provide  efficient  performance  for  both  non-DAMA  and 
DAMA  operations.  This  report  describes  the  methods  of  analyzing  the  new  proposed 
protocol  for  the  OTCIXS  network  (hereafter  referred  to  as  OTCIXS  II)  for  both  non- 
DAMA  and  DAMA  operations.  The  primary  focus  of  this  analysis  is  on  message 
throughput  times,  queue  wait  times,  message  throughput  rate,  and  network  transmission 
utilization.  These  values  are  obtained  for  various  scenario/exercises  consisting  of  different 
combinations  of  total  messages  per  hour  generated  by  the  simulation,  different  number  of 
high  and  low  priority  network  access  request  slots,  and  with  and  without  automatic 
rescheduling  of  subscriber  access  to  the  network  for  data  transmission. 

The  different  scenario/exercise  parameters,  as  applicable,  are  used  with  both  the 
OTCIXS  I  and  OTCIXS  II  simulations  to  provide  comparative  results  between  the  old 
and  newly  proposed  protocols.  The  simulation  program  and  network  model  are  only 
approximations  of  real  world  operations  but  are  providing  both  OTCIXS  I  and  OTCIXS 
II  simulation  test  results,  at  least  a  comparison  of  the  newly  proposed  protocol  to  the  old 
can  be  reasonably  performed.  The  simulation  of  the  newly  proposed  protocol  will  exhibit 
both  the  errors  and  deficiencies  exhibited  by  the  old;  by  providing  results  for  both 
protocols,  it  is  assumed  that  reasonable  conclusions  can  be  drawn  from  the  simulation 
results. 

B.  BACKGROUND. 

The  increasing  requirements  for  satellite  communications  links  using  limited 
number  of  available  satellite  channels  have  led  to  the  development  of  DAMA  which 
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permits  several  UHF  SATCOM  subsystems  to  share  a  single  25  kHz  satellite  channel. 
Either  the  Fleet  Satellite  (FLTSAT)  or  Leased  Satellite  (LEASAT)  can  be  used  for 
OTCIXS  operations.  A  subscriber  designated  as  a  Net  Control  Station  (NCS)  coordinates 
the  use  of  the  OTICXS  network.  Surface  ships  and  shore  sites  are  capable  of  assuming 
the  NCS  function.  The  NCS  receives,  queues,  and  acknowledges  receipt  of  subscriber 
access  requests.  The  NCS  assigns  transmission  times  to  all  high  priority  (flash)  requests, 
scheduled  low  priority  (immediate)  broadcast  requests,  and  finally  non-scheduled 
immediate  requests.  Once  a  subscriber  has  been  authorized  by  the  NCS  to  transmit  its 
message  data,  the  subscriber  initiates  message  transmission;  in  the  proposed  OTCIXS  II 
protocol,  the  subscriber  will  not  be  preempted  by  other  message  transmissions  regardless 
of  precedence  of  the  message  involved. 

DAMA  divides  channel  transmission  into  1.38667  second  intervals  called  frames. 
Each  frame  is  divided  into  burst  transmission  subintervals  called  slots.  There  are  several 
groupings  of  slots  within  a  frame;  these  are  called  frame  formats.  Frame  formats  consist 
of  combinations  of  slots  supporting  user  transfer-rate  to  DAMA  burst-rate  transmissions. 
User  rates  vary  from  75  bits  per  second  (bps)  to  16,000  bps;  DAMA  bursts  rates  vary 
from  9,600  to  32,000  symbols  per  second.  Some  slots  are  dedicated  for  DAMA 
operations  and  are  not  available  for  general  use.  The  rest  of  the  transmission  time  in  a 
frame  is  allocated  to  user  slots.  Each  network  is  assigned  a  slot  to  use  based  on  those 
available  within  the  active  frame  format  at  the  time  the  network  is  attached  to  DAMA. 

It  was  assumed  that  user  networks  can  operate  in  a  DAMA  environment  with  little 
or  no  change  to  the  program  software.  However,  analysis  of  the  OTCIXS  network 


149 


indicates  that  this  is  not  a  correct  assumption.  A  model  of  the  OTCIXS  network  for  non- 
DAMA  and  DAMA  operations  was  developed  to  analyze  OTCIXS  performance.  Results 
from  this  analysis  show  degraded  operations  in  the  DAMA  environment.  It  is  therefore 
anticipated  that  a  new  OTCIXS  protocol  would  need  to  be  defined  to  operate  in  the 
DAMA  environment  without  suffering  the  degradation  of  the  current  network  protocol. 
This  analysis  is  an  attempt  to  determine  the  performance  characteristics  of  the  newly 
proposed  OTCIXS  II  protocol.  Only  the  non-DAMA  operation  of  the  current  OTCIXS 
network  operations  was  analyzed  since  the  DAMA  operation  has  degraded  performance, 
which  the  newly  proposed  protocol  is  intended  to  correct. 


C.  NETWORK  SIMULATION  SUMMARY. 

The  analysis  of  network  performance  used  several  different  items  of  data  to 
provide  the  various  different  simulations.  These  items  included  subscriber  message  queue 
wait  times,  message  throughput  times,  message  throughput  rates,  and  network  utilization. 
These  were  measured  for  both  the  OTCIXS  I  and  the  proposed  OTCIXS  II  protocol. 
The  effects  of  missed  or  lost  messages  were  not  key  concerns  of  this  effort.  The  loss  of 
traffic  is  caused  by  many  factors  including  the  quality  of  transmit/receive  equipment, 
atmospheric  conditions,  and  satellite  performance  characteristics;  these  are  difficult  to 
mode  and  only  a  crude  approximation  can  be  simulated.  The  loss  of  messages  is  assumed 
to  affect  both  protocols  the  same;  thus,  the  main  emphasis  is  on  determining  how  the 
differences  in  the  two  protocols  effect  overall  performance.  Rather  than  concentrating  on 
those  functions  of  network  performance  related  to  transmission  quality,  this  analysis 
concentrates  on  the  network  access  and  control  characteristics. 
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Each  protocol  operates  in  cycles.  These  cycles  provide  the  ability  for  subscribers 
to  request  and  use  the  network  for  transmitting  data  to  other  subscribers.  The  different 
protocols  manage  these  cycles  differently.  This  analysis  measures  the  functions  affected 
by  the  different  cycle  management  schemes  and  attempts  to  compare  OTCIXS I 
performance  to  that  of  the  proposed  OTCIXS  II. 

Performance  of  both  protocols  is  measured  in  a  non-DAMA  environment.  Both 
protocols  operate  in  non-DAMA  environments,  and  this  provides  compatible  results  that 
can  be  used  to  compare  one  protocol  to  the  other.  The  proposed  OTCIXS  II  protocol  is 
also  measured  in  a  DAMA  environment;  these  results  are  useful  in  determining  and 
degradation  of  OTCIXS  II  performance  in  a  DAMA  environment. 

1.  Queue  Wait  Times. 

Queue  wait  time  is  the  measure  of  time  between  receipt  of  a  message  in  a 
subscriber  and  the  transmission  of  the  message  over  the  network,  i.e.,  the  amount  of  time 
messages  are  queued  in  the  subscriber  before  transmission.  This  time  includes  delays  that 
result  from  access  transmission  requests,  request  collisions,  cycle  times,  and,  in  the  case  of 
the  proposed  OTIXS II  protocol,  access  scheduling.  The  shorter  the  queue  wait  time  for 
a  message  the  timelier  the  data  in  the  message  is.  Thus,  shorter  queue  wait  times  indicate 
better  performance.  This  allows  measuring  the  effects  of  the  different  cycle  management 
techniques  on  network  access. 

2.  Message  Throughput  Times. 

Message  throughput  time  is  the  measure  of  time  between  receipt  in  the  source 
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device  to  receipt  of  the  message  in  the  destinations  device;  message  throughput  is  divided 
into  subscriber  to  subscriber  (link  controller  to  link  controller)  and  tactical  data  processor 
(TDP)  or  teletype  (TTY)  to  TDP  or  TTY  throughput  times.  These  times  are  useful  in 
measuring  the  effects  transmitting  data  more  than  one  time.  The  OTCIXS  I  protocol 
transmits  TDP  data  separately  from  TTY  data;  the  OTCIXS II  proposed  protocol  does 
not.  Message  throughput  time  provides  a  method  of  measuring  this  difference  in 
operation. 

3.  Message  Throughput  Rate. 

Message  throughput  rates  are  the  measure  of  number  of  messages  over  the 
network.  For  purposes  of  this  analysis,  message  throughput  rate  is  the  number  of 
messages  transferred  from  one  subscriber  to  another  subscriber  or  subscribers.  This 
measure  is  used  to  attempt  to  determine  the  upper  bound  of  message  throughput  for  the 
network.  This  is  needed  to  determine  if  the  network  protocol  is  anticipated  to  satisfy  the 
specification  objective  of 200  messages  per  hour. 

4.  Network  Utilization. 

Network  Utilization  is  the  measure  of  network  time  used  for  data  transmission. 
This  measure  is  a  percentage  of  the  total  available  time  and  the  amount  of  time  used  to 
transmit  network  control  data,  access  requests,  and  subscriber  data.  Network  utilization 
measures  the  amount  of  network  time  lost  due  to  idle  time,  guard  times,  and  network 
inefficiencies. 
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APPENDIX  C  -  Section  C2 


DESCRIPTION 


A.  OTCIXS I  MODEL. 

The  OTCIXS  I  model  is  based  on  the  currently  operational  protocol  for  the 
OTCIXS  network.  This  protocol  includes  variable  network  access  request  time  slots, 
data,  transmission  units  which  include  either  datalink  or  teletype  messages,  but  not  both  at 
the  same  time,  and  transmission  of  the  net  control  block  (NCB)  before  transmission  of 
each  copy  of  the  transmission  unit  (TU).  The  network  is  designed  to  operate  in  a  non- 
DAMA  UHF  environment.  Subscribers  gain  access  to  the  network  by  demanding  use  of 
the  network,  and  can  preempt  use  of  the  network  from  lower  priority  message 
transmissions. 

Subscribers  in  the  OTCIXS  I  network  gain  access  to  the  network  to  transmit  data 
by  transmitting  access  requests  during  periods  of  time  reserved  for  request  demands. 
There  is  one  high  priority  request  time  slot  (PRTS)  reserved  exclusively  for  use  by 
subscribers  who  have  flash  message  traffic  to  transmit.  There  are  up  to  19  general  access 
request  time  slots  (GATS)  for  use  by  subscribers  with  flash  or  immediate  message  traffic. 
The  PRTS  and  GATS  intervals  are  discontinued  once  a  subscriber  demands  use  of  the 
network.  Thus,  any  one  cycle  has  between  one  and  twenty  request  time  slots,  but  does 
not  necessarily  have  all  twenty  every  time. 

The  NCB  precedes  the  request  slots  in  every  cycle.  After  the  request  time  slots 
interval  is  the  time  dedicated  to  the  subscribers  for  transmission  of  data.  A  cycle  consists 
of  the  NCB,  the  PRTS  and  GATS,  and  one  copy  of  a  data  TU  if  there  is  one.  An  idle 
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cycle  is  a  cycle  during  which  not  data  is  transmitted.  A  single  access  time  slot  (SATS) 
cycle  is  a  cycle  during  which  one  copy  of  a  data  TU  is  transmitted.  Each  copy  of  a 
multiple  copy  TU  is  preceded  by  a  NCB  transmission. 

In  summary,  the  OTCIXS I  network  protocol  preceded  subscriber  transmission 
with  the  transmission  of  a  NCB.  Up  to  twenty  request  time  slots  were  provide  to 
subscribers  to  demand  access  to  the  network,  but  the  request  time  slot  interval  is 
discontinued  when  the  first  demand  transmission  takes  place;  and  each  copy  of  a  TU  is 
preceded  by  the  transmission  of  the  NCB.  Also,  the  model  developed  to  analyze  OTCIXS 
I  performance  does  not  include  scheduled  broadcast  traffic. 

The  simulation  program  was  designed  to  implement  these  functions  with 
assumptions  on  how  the  network  operated.  These  assumptions  include  the  effects  of 
signal-to-noise  on  data  transmissions,  cryptographic  equipment  probability  for  sequence 
failure,  and  message  throughput  distributions.  The  simulation  program  provides  a  means 
of  analyzing  network  performance  based  on  the  functional  operation  of  the  network  and 
algorithms  that  model  performance  characteristics,  assumed  or  known  to  occur  in  an  UHF 
environment. 

B.  OTCIXS  n  MODEL. 

The  proposed  OTCIXS  II  network  protocol  incorporates  several  changes  to  the 
current  protocol.  These  include  providing  all  request  time  slots  in  every  cycle;  sending  all 
copies  of  a  data  TU  when  network  access  is  granted  by  the  NCS;  and  once  the  network  is 
granted  to  a  subscriber  to  transmit  data,  no  other  subscriber  can  preempt  the  network 
from  the  transmitting  subscriber.  The  specific  details  of  how  the  OTCIXS  II  network 
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operates  can  be  found  in  the  body  of  this  thesis.  The  model  provides  the  ability  to  perform 
different  variations  in  network  operations. 

The  OTCIXS II  protocol  allows  for  a  variable  number  of  flash  and  immediate 
message  random  access  time  slots  (RATS);  the  NCB  identifies  how  many  of  each  type  of 
access  time  slot  is  available  during  the  next  cycle.  Subscriber  demands,  received  as 
requests  transmitted  during  the  RATS,  for  access  to  the  network  to  transmit  data  are 
scheduled  by  the  NCS  and  queued  on  a  first-in,  first-out  (FIFO)  order  by  request  priority. 
All  allocated  request  time  slots  are  provided  during  each  cycle,  and  the  request  time  slot 
interval  is  not  truncated  when  the  first  demand  is  transmitted,  as  is  the  case  in  the 
OTCIXS  I  protocol.  The  OTCIX II  protocol  currently  allows  high  priority  requests  to 
use  any  of  the  available  request  slots,  and  are  not  limited  to  using  only  the  dedicated  high 
priority  request  slot(s).  The  OTCIXS  II  protocol  provides  a  mechanism  to  schedule 
subscribers  without  requiring  them  to  demand  access  during  the  request  time  slot  interval. 

The  two  methods  currently  under  consideration,  that  have  been  modeled,  are  “piggy¬ 
backing”,  i.e.,  a  request  for  access  in  the  TU,  and  providing  a  list  of  subscribers  that  are 
automatically  polled,  i.e.,  automatically  scheduled  for  network  access  without  the 
necessity  of  demanding  access. 

The  OTCIXS  II  protocol  provides  for  transmission  of  all  buffered  messages  in  the 
subscriber  station  when  access  to  the  network  is  granted.  The  TU  will  contain  either  flash 
and  immediate  datalink  and  teletype  messages.  TUs  are  limited  to  10103  bytes  of  message 
data  plus  the  overhead  data  bytes  needed  for  the  TU.  This  is  intended  to  reduce  the 
number  of  access  requests  a  subscriber  should  need  to  make  to  transmit  buffered 
messages. 
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The  simulation  program  has  been  modified  to  perform  these  functions  based  on  the 
assumptions  and  message  generation  algorithms  used  in  the  OTCIXS I  simulation 
program.  As  much  as  possible  of  the  original  simulation  model  has  been  maintained  with 
the  new  functional  definitions  and  performance  characteristics  layered  onto  them.  This 
will  provide  some  comparative  analysis  of  the  OTCIXS  II  performance  with  respect  to  the 
OTCIXS  I  analysis. 

1.  OTCIXS  Simulation  Components. 

The  OTCIXS  simulation  consists  of  three  components.  The  first  is  the  program; 
the  set  of  instructions  that  perform  the  functional  processing  of  the  network.  The  second 
is  the  network  model;  the  definitions  of  the  subscriber  and  message  generation 
characteristics.  The  third  is  the  setup  file;  the  parameters  that  allow  quick  and  simple 
modifications  of  the  data  or  processing  of  the  simulation  program. 

The  simulation  program  consists  of  the  algorithms  for  performing  the  functionally 
processing  of  the  OTCIXS  network.  The  algorithms  for  generating  messages,  simulating 
induced  noise  errors,  and  simulating  cryptographic  equipment  synchronization  failures 
have  been  left  as  originally  designed.  The  OTCIXS  I  non-DAMA  processing  has  also 
been  left  intact.  The  changes  that  have  been  made  incorporated  the  new  proposed 
protocol  functionality/timing  processing  described  in  body  of  this  thesis.  The  proposed 
new  protocol  processing  is  designed  to  perform  the  same  cyclic  functional  operations 
whether  non-DAMA  or  DAMA.  The  cycle  interval  times  are  adjusted  to  DAMA  time  slot 
values  when  the  DAMA  environment  is  being  simulated.  The  message  generation 
processing  uses  the  three  equations  for  message  arrival  patterns:  Poisson,  Negative 
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Binomial,  and  Periodic.  However,  the  simulation  program  originally  designed  specified 
message  traffic  per  hour  as  a  parameter  defined  in  the  model  definition.  The  program  has 
been  modified  so  that  the  model  defines  the  percentage  of  total  message  per  hour  a 
specific  subscriber  generates,  and  the  setup  file  defines  the  actual  messages  per  hour  value 
for  the  network  as  a  whole.  This  change  allows  for  more  flexibility  in  simulating  various 
different  traffic  rates  without  having  to  redefine  the  entire  model.  The  message  multiplier 
parameter  in  the  setup  file  is  still  available,  but  its  use  affects  subscriber  percentage,  not 
the  actual  traffic  rate. 

a.  Model  Description. 

The  simulation  program  consists  of  the  algorithms  needed  to  simulate  the 
network  operation.  The  data  describing  the  subscribers,  the  types  and  characteristics  of 
messages,  and  the  frequency  with  which  each  subscriber  generates  the  different  types  of 
messages  is  provided  in  a  network  description  file  (NDF).  The  NDF  is  produced  by 
describing  the  subscriber  and  network  characteristics  in  a  network  simulation  description 
language  (NSDL).  The  source  is  then  converted  into  a  binary  interpretation  used  by  the 
simulation  program.  Appendix  A  is  a  listing  of  the  source  NSDL  used  for  this  analysis. 
The  following  summarizes  the  characteristic  used  to  analyze  the  proposed  OTCIXS II 
protocol: 

1 .  The  network  model  consists  of  40  subscribers  generating  a  non-uniform 
distribution  of  messages.  This  is  accomplished  by  defining  six  of  the  subscribers  as  type  1 
(best),  or  type  2  (good)  quality  transmit  stations,  generating  approximately  78  to  80 
percent  of  the  message  traffic.  The  remainder  of  the  subscriber  stations  are  type  2  or  type 
3  (poorest)  quality  transmit  stations  equally  generating  20  percent  of  the  message  traffic. 
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2.  The  model  is  designed  to  produce  a  mix  of  80  percent  immediate  and  20 
percent  flash  messages,  with  90  percent  of  the  messages  being  datalink  and  10  percent 
being  teletype  messages. 

3.  Message  generation  distribution  is  poisson  for  all  subscribers. 

4.  The  traffic  load,  messages  per  hour,  is  specified  in  the  program  setup 
file  and  is  varied  to  simulate  different  traffic  loads. 

5.  The  model  is  defined  to  generate  25  percent  discrete-addressed  and  75 
percent  collective-addressed  messages.  There  are  six  collective  addressees  defined  with 
approximately  equal  probability  for  selection. 

6.  Each  subscriber  has  only  one  of  the  collective  address  values  in  its 
guard  list.  The  six  collective  address  values  are  equally  distributed  among  the  40 
subscriber  stations. 

b.  Setup  File  Description. 

The  program  setup  file  allows  the  operator  to  fine  tune  the  exercise  for  the 
current  simulation.  The  setup  file  definition  is  functionally  the  same  as  the  originally 
constructed  for  the  OTCIXS  I  simulation.  However,  modifications  have  been  made,  these 
include;  adding  parameters  to  change  the  traffic  load  (messages  per  hour),  the  number  of 
RATS,  the  number  of  RATS  to  be  used  for  high  priority  requests,  whether  automatic 
piggy-backed  requests  processing  is  enabled,  and  selection  of  frequent  users  to  be  included 
in  the  automatic  poll  list.  Appendix  B  describes  the  setup  file,  including  changes,  used  for 
this  analysis. 

Some  parameters  have  been  deleted  since  they  were  not  used:  such  things 
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as  the  header  length  of  teletype  messages  and  block  byte  count  size  parameter  definition 
have  been  eliminated.  The  teletype  message  header  size  parameter  has  been  deleted;  the 
assumption  is  that  the  header  and  end  of  message  bytes  are  included  in  the  generated 
message  size  and  do  not  need  to  be  added  in  separately.  The  block  byte  count  size 
parameter  is  calculated  based  on  the  maximum  block  byte  count  size  parameter  specified 
in  the  setup  file. 

Several  parameters  in  the  setup  file  were  set  to  the  same  values  for  all 
scenarios  tested.  The  network  is  defined  to  transmit  8-bit  characters  at  2400  PBS.  The 
options  used  to  differentiate  the  various  scenarios  and  exercises  are; 

1 .  The  number  of  messages  generated  per  hour 

2.  The  number  of  request  slots  available  per  cycle 

3.  Whether  the  new  protocol  (OTCIXS II)  or  the  old  protocol  is  being 

simulated 

4.  Whether  DAMA  mode  processing  is  enabled  for  an  OTCIXS  II 

simulation 

5.  Whether  piggy-backed  rescheduling  is  enabled 

6.  Whether  frequent  user  polling  is  enabled  and  the  subscribers  to  be 

polled. 


2.  Automatic  Rescheduling. 

The  OTCIXS  uses  a  demand  request  protocol  to  gain  access  of  the  network  to 
transmit  data.  When  several  subscribers  are  actively  transmitting  data  on  the  network. 
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there  is  a  likelihood  that  more  than  one  subscriber  will  transmit  a  request  at  the  same  time. 
This  contention  for  the  limited  number  of  request  slots  results  in  poor  use  of  the  network, 
depending  on  such  factors  as  how  many  requests  have  already  been  scheduled  and  the 
precedence  of  the  requests  that  were  lost.  Automatic  rescheduling  of  subscribers  has  been 
considered  as  a  method  of  reducing  the  number  of  requests  that  would  have  to  be  made, 
thus  reducing  the  contention  fro  a  request  slots  available.  The  two  methods  under 
consideration  at  this  time  are  piggy-back  and  frequent  user  polling. 

a.  Piggy-backed  Requests. 

A  piggy-backed  request  would  be  implemented  by  putting  data  into  the  TU 
header  requesting  use  of  the  network  as  soon  as  available,  based  on  the  priority  of  the  data 
to  be  transmitted.  In  essence,  the  request  transmission  is  piggy-backed  onto  the  data 
transmission.  Subscribers  can  piggy-back  a  request  based  on  various  criteria,  receipt  of 
more  data  after  transmission  has  begun  or  prediction  that  more  data  will  soon  arrive.  The 
simulation  program  has  been  updated  to  emulate  the  first  option.  The  simulation  program 
determines  if  additional  messages  have  been  received  in  the  Link  Controller  or  are  about 
to  be  transmitted  from  the  TDP  to  the  Link  Controller.  If  either  of  these  conditions  is 
true,  a  piggy-backed  request  is  indicated  and  the  subscriber  is  automatically  rescheduled 
for  network  access.  No  predictive  algorithms  have  been  modeled. 

b.  Frequent  Users  Polling  List. 

A  polling  list  rescheduling  mechanism  has  been  built-in  to  the  simulation 
program.  When  a  subscriber  transmits  data  on  the  network,  the  subscriber’s  identification 
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number  is  checked  to  see  if  it  is  in  the  frequent  users  list.  If  it  is,  the  subscriber  is 
automatically  rescheduled  for  an  immediate  message  transmission.  Subscribers  are  put 
into  the  frequent  users  list  by  parameters  entered  in  the  setup  file.  If  no  subscribers  are 
identified  as  frequent  users,  then  ffequesnt  user  polling  is  in  effect  disabled.  The  model 
has  been  modified  so  that  a  frequent  user  subscriber  always  transmits  when  selected,  in 
order  to  keep  the  frequent  user  in  the  scheduling  list.  This  has  resulted  in  emulation  a  no¬ 
data  informing  NCB  that  the  network  is  not  needed,  but  transmission  of  data  indicating 
nothing  is  being  sent  or  detection  of  a  quiescent  channel. 
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APPENDIX  C  -  Section  C3 


PERFORMANCE  RESULTS 


A.  TEST  CRITERIA. 

In  section  2  the  model  definition  and  setup  files  are  described;  these  files  provide 
the  simulation  program  user  the  capability  to  simulate  or  test  a  large  number  of  different 
combinations  of  network  operational  characteristics.  This  section  discusses  the  tests  that 
were  run  and  their  results.  To  achieve  the  goals  of  this  analysis  only  a  limited  set  of  data 
was  required.  Only  the  necessary  combinations  of  network  characteristics  were  set  up  and 
tested  to  obtain  this  data. 

The  data  for  this  analysis  was  obtained  by  executing  the  simulation  program  using 
the  model  and  setup  file  data  described  in  section  II.  However,  the  simulation  program 
gives  only  a  rough  approximation  of  the  real  world  operation.  The  simulated  testing  of 
the  OTCIXS II  was  based  on  the  real  world  OTCIXS I  historical  program  data,  and 
cannot  for  certain  determine  whether  the  specified  requirements  will  be  satisfied.  The  test 
results  provide  data  for  basing  comparisons  on  how  different  parameters  affect  operations. 
This  is  also  the  base  for  comparing  OTCIXS  I  and  OTCIXS  II  performance.  The 
deficiencies  in  the  data  for  OTCIXS  I  testing  are  the  same  for  OTCIXS  II  test  data.  The 
same  routines  and  algorithms  were  used  for  both  protocols  with  the  only  differences  being 
in  the  network  cycle  control  routines.  The  validity  of  the  conclusions  drawn  in  the 
analysis  are  based  on  the  validity  of  the  program  and  model.  Therefore,  it  is  assumed, 
without  proof,  that  the  program  and  model  are  close  approximations  and  provide  results 
that  are  reasonable  indications  of  performance. 
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Given  the  above  assumption,  the  OTCIXS  II  proposed  protocol  tests  use  a 
minimum  and  maximum  cycle  time  scenario.  For  the  purposes  of  testing,  the  minimum 
cycle  time  si  the  net  cycle  using  one  high  priority  and  two  low  priority  RATS.  The 
maximum  cycle  time  is  the  net  cycle  using  two  high  priority  an  six  low  priority  RATS. 
These  scenarios  are  tested  with  an  increasing  traffic  load;  the  tests  are  performed  again 
using  the  two  different  rescheduling  techniques. 

The  minimum  RATS  scenario  produces  the  shortest  OTCIXS  II  network  cycle 
times,  but  also  produces  the  greatest  contention.  The  maximum  RATS  scenario  produces 
the  longest  cycle  times,  but  also  reduces  overall  contention.  The  test  data  showed  the 
following  contention/collision  performance.  The  minimum  RATS  scenario  went  from 
1.7%  of  the  total  number  of  requests  colliding  at  100  messages  per  hour  to  8.6%  of  the 
total  number  of  requests  colliding  at  400  messages  per  hour.  The  maximum  RATS 
scenario  went  from  2.6%  at  100  messages  per  hour  to  6.3%  at  400  messages  per  hour. 
The  minimum  scenario  had  7  collisions  at  100  messages  per  hour  and  83  collisions  at  400 
messages  per  hour.  The  maximum  scenario  had  1 1  collisions  at  100  messages  per  hour 
and  51  collisions  at  400  messages  per  hour.  The  minimum  scenario  had  more  total  cycles 
with  an  approximate  average  of 490  cycles  per  hour.  The  minimum  scenario  provided 
fewer  overall  opportunities  for  subscribers  to  request  access  to  the  network  (based  on  980 
cycles  per  hour  time  3  RATS  per  cycle  for  a  minimum  and  490  times  8  for  the  maximum) 
and  also  had  a  higher  percentage  and  total  number  of  collisions.  The  conclusion  is  the 
minimum  scenario  provides  shorter  cycles  but  reduces  the  opportunity  to  request  access  to 
the  network.  However,  this  reduced  access  does  not  necessarily  mean  poorer  use  of  the 
network.  At  lower  traffic  loads  many  of  the  cycles  are  idle,  i.e.,  there  is  no  data  to 
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transmit.  The  following  test  cases  are  designed  to  show  if  the  decreased  number  of  RATS 
degrade  or  improve  network  performance.  The  OTCIXS II DAMA  mode  is  also  included 
with  the  non-DAMA  mode  results  for  both  the  minimum  and  maximum  scenarios.  The 
time  interval  difference  skews  the  network  cycle  times  higher,  but  the  operational  trends 
should  still  be  comparable. 

Table  C3-1  contains  the  simulation  results  for  the  OTCIXS  I  network.  This  data  is 
used  in  comparing  the  results  from  the  OTCIXS  II  simulation.  The  following  subsections 
analyze  how  these  different  extremes  affect  message  wait  times,  subscriber  to  subscriber 
times,  and  network  utilization. 

B.  SCENARIO  1:  MINIMUM  CYCLE. 

Table  C3-2  and  C3-3  summarizes  the  test  result  for  the  minimum  cycle  scenario. 
Figures  C3-1  and  C3-2  are  graphical  interpretations  of  the  result  values  for  the  subscriber 
queue  wait  and  the  subscriber  to  subscriber  service  times  against  those  of  OTCIXS  I.  The 
data  compared  to  table  C3-1  shows  very  similar  performance.  The  data  shows  that 
OTCIXS  I  queue  wait  times  for  high  priority  messages  are  shorter  than  those  for  OTCIXS 
n,  but  OTCIXS  n  low  priority  queue  wait  times  are  shorter  than  OTCIXS  I.  The  DAMA 
operation  uses  the  network  time  nearly  the  same  as  the  non-DAMA  operation,  however 
the  times  are  approximately  30%  higher.  The  effective  message  throughput  rates  per  hour 
are  also  very  close  the  same  for  OTCIXS  I  and  OTCIXS  II  non-DAMA,  and  OTCXS II 
DAMA. 
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Table  C3-1.  OTCIXS  I  Simulation  Data  Results  (non-DAMA  Mode  in  seconds) 


Messages 
per  hour 

1 

Wait  Queue 
Times 

1 

End  to  End 
Delivery 

i 

Contrc 

Cont 

Ser 

>ller  to 

roller 

rice 

l 

Utility 

# 

Request 

1 

Sched 

Best 

ACT 

EFF 

Lo 

Hi 

Lo 

Hi 

Lo 

Hi 

% 

Slots 

PI 

mm 

89.0 

20.8 

8.7 

62.0 

48.5 

■ 

BiiS 

27.8 

19  1 

n 

El 

ESI 

129.8 

36.8 

11.0 

65.6 

41.3 

■ 

II 

19  1 

El 

El 

205.4 

1 

Kill 

11.8 

128.2 

■ 

El 

■  ■ 

19  1 

El 

El 

ESI 

244.8 

1 

E8H 

24.8 

336.3 

■ 

ERIE 

KTtl 

56.7 

19  1 

El 

El 

Table  C3-2.  OTCIXS  II  Minimal  Cycle  Time  (non-DAMA  Mode  in  seconds) 
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Table  C3-3.  OTCIXS  II  Minimal  Cycle  Time  (DAMA  Mode  in  seconds) 
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C.  SCENARIO  2:  MAXIMUM  CYCLE. 

Tables  C3-4  and  C3-5  summarize  the  test  results  for  the  maximum  cycle  scenario. 
Figures  C3-3  and  C3-4  are  graphical  interpretations  of  the  results  values  for  the  subscriber 
queue  wait,  and  subscriber  to  subscriber  service  times.  The  data  compared  to  table  C3-1 
shows  that  high  priority  subscriber  to  subscriber  times  for  both  OTCIXS  I  and  OTCIXS  II 
non-DAMA  are  similar,  with  OTCIXS  II  DAMA  being  higher.  Low  priority  OTCIXS  II 
non-DAMA  times  were  lower  than  either  OTCIXS  I  or  OTCIXS  II  DAMA  Subscriber 
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queue  wait  time  results  were  similar  to  subscriber  to 

Table  C3-4.  OTCIXS II  Maximum  Cycle  Time  (non-DAMA  Mode  in  seconds) 
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Table  C3-5.  OTCIXS  II  Maximum  Cycle  Time  (DAMA  Mode  in  seconds) 
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Subscriber  service  times  except  that  OTCIXS  I  high  priority  times  were  lower.  The 
DAMA  operation  uses  the  network  time  slightly  more  than  the  non-DAMA  operation, 
however  OTCIXS  I  utilization  percentages  were  higher.  The  effective  message 
throughput  rate  per  hour  for  non-DAMA  was  slightly  higher  than  OTCIXS  I  while 
OTCIXS  H  DAMA  was  significantly  higher  than  OTCIXS  I. 


D.  SCENARIO  3:  MINIMAL  CYCLE  WITH  PIGGY-BACK  SCHEDULING. 

Tables  C3-6  and  C3-7  summarize  the  test  results  for  the  minimal  cycle  scenario 
with  piggy-back  scheduling.  Figures  C3-5  and  C3-6  are  graphical  interpretations  of  the 
result  values  for  subscriber  to  subscriber  service  and  the  subscriber  queue  wait  times 
against  those  for  the  minimum  cycle  with  no  rescheduling.  The  subscriber  to  subscriber 
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service  time  data  from  tables  C3-6  and  C3-7  compared  to  tables  C3-2  and  C3-3  show  that 
both  non-rescheduled  and  piggy-backed  OTCIXS II  subscriber  to  subscriber  service  and 
subscriber  queue  wait  times  for  either  high  or  low  priority  messages  are  quite  similar. 

E.  SCENARIO  4:  MINIMUM  CYCLE  WITH  FREQUENT  USER  POLLING. 

Tables  C3-8  and  C3-9  summarize  the  test  results  for  the  minimum  cycle  scenario 
with  frequent  user  polling.  Figures  C3-7  and  C3-8  are  graphical  interpretations  of  the 
result  values  for  subscriber  to  subscriber  and  subscriber  queue  wait  times  against  those  for 
the  minimum  cycle  with  no  rescheduling.  The  subscriber  to  subscriber  service  time  data 
from  tables  C3-8  and  C3-9  compared  to  tables  C3-2  and  C3-3  show  that  both  non-DAMA 
frequent  user  polled  and  non-rescheduled  high  priority  messages  result  in  similar 
performance  during  scenarios  with  less  than  400  messages  per  hour  generated.  This  is 
also  true  for  DAMA  high  priority  messages.  With  low  priority  messages,  non-rescheduled 
non-DAMA  performed  slightly  better  than  low  priority  frequent  user  non-DAMA,  while 
the  poorest  performance  came  from  both  frequent  user  and  non-rescheduled  DAMA.  The 
effective  message  throughput  per  hour  for  frequent  user  polling  was  slightly  higher  for 
DAMA,  but  for  the  most  part  less  for  non-DAMA. 
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Table  C3-6.  OTCIXS II  Minimum  Cycle  Time/Piggy-Backed  Rescheduling 
(non-DAMA  Mode  in  seconds) 
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Table  C3-7.  OTCIXS  II  Minimum  Cycle  Time/Piggy-Backed  Rescheduling 

(DAMA  Mode  in  seconds) 
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Table  C3-8.  OTCIXS  II  Minimum  Cycle  Time  Frequent  User  Polling 
(non-DAMA  Mode  in  seconds) 
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Table  C3-9.  OTCIXS II  Minimum  Cycle  Time  Frequent  User  Polling 
(DAMA  Mode  in  seconds) 
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per  hour 

1 

Wait  Queue 
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F.  SCENARIO  5:  MAXIMUM  CYCLE  WITH  PIGY-BACK  SCHEDULING. 

The  tables  C3-10  and  C3-1 1  summarize  the  test  results  for  the  maximum  cycle 
scenario  with  piggy-back  rescheduling.  Figures  C3-9  and  C3-10  are  graphical 
interpretations  of  the  result  values  for  subscriber  to  subscriber  queue  wait  times  against 
those  for  the  maximum  cycle  with  no  rescheduling.  The  subscriber  to  subscriber  service 
time  data  from  tables  C3-10  and  C3-1 1  compared  to  table  C3-4  and  C3-5  show  non- 
DAMA  high  priority  messages  tended  to  be  lower  overall,  with  piggy-back  scheduling 
times  shorter  during  traffic  loads  of  200  to  300  messages  per  hour,  but  increasing 
significantly  for  traffic  loads  of  greater  than  300  messages  per  hour.  The  same  is  true  for 
'  non-DAMA  low  priority  messages.  All  DAMA  subscriber  to  subscriber  service  times 
tended  to  be  higher  overall.  Subscriber  queue  wait  times  followed  the  same  trend  as 
subscriber  to  subscriber  service  times.  Network  utilization  for  piggy-back  scheduling  and 
non-rescheduled  non-DAMA  operations  were  fairly  similar  until  the  300  message  level 
when  non-rescheduled  percentages  were  higher.  Network  utilization  for  piggy-back 
scheduling  and  non-scheduled  DAMA  operations  were  fairly  even.  Effective  message 
throughput  per  hour  was  similar  between  piggy-back  scheduling  and  non-scheduling. 
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Table  C3-10.  OTCIXS II  Maximum  Cycle  Time/Piggy-Back  Rescheduling 
(non-DAMA  Mode  in  seconds) 
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Table  C3-1 1.  OTCIXS  II  Maximum  Cycle  Time/Piggy-Back  Rescheduling 

(DAMA  Mode  in  seconds) 
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G.  SCENARIO  6:  MAXIMUM  CYCLE  WITH  FREQUENT  USER  POLLING. 

Tables  C3-12  and  C3-13  summarize  the  test  results  for  the  maximum  cycle  scenario 
with  frequent  user  polling.  Figures  C3-1 1  and  C3-12  are  graphical  interpretations  of  the 
result  values  for  subscriber  to  subscriber  service  and  subscriber  queue  wait  times  against 
those  of  the  maximum  cycle  with  no  rescheduling.  The  subscriber  to  subscriber  service 
time  data  from  tables  3-12  and  C3-13  compare  to  tables  C3-4  and  3-5  show  non-DAMA 
high  priority  message  sendee  times  the  shortest  and  fairly  even.  Non-rescheduled  non- 
DAMA  low  priority  service  times  were  better  than  their  frequent  user  polled  counterparts. 
Similarly  to  scenario  5,  all  DAMA  subscriber  to  subscriber  service  times  tended  to  be 
higher  overall.  Subscriber  queue  wait  times  paralleled  the  same  trend  as  subscriber  to 
subscriber  which  tends  to  be  much  higher  than  its  non-rescheduled  counterpart.  Non- 
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rescheduled  network  utilization  percentages  were  slightly  higher  than  frequent  user 

polling,  while  effective  message  throughput  per  hour  was  fairly  even. 

Table  C3-12  OTCIXS II  Maximum  Cycle  Time  Frequent  User  Polling 
(non-DAMA  Mode  in  seconds) 
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Table  C3-13  OTCIXS  II  Maximum  Cycle  Time  Frequent  User  Polling 
(DAMA  Mode  in  seconds) 
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H.  SUMMARY  AND  CONCLUSIONS. 

The  OTCIXS  I  upper  effective  message  throughput  is  about  300  messages  per 
hour.  The  OTCIXS  II  non-DAMA  upper  effective  message  throughput  was  about  250 
messages  per  hour.  While  OTCIXS  II  DAMA  appears  to  have  an  upper  effective  message 
throughput  of  about  325  messages  per  hour,  there  seems  to  be  some  timing  conditions 
involved.  Under  certain  conditions  OTCIXS  II  DAMA  can  reach  more  than  300 
messages  per  hour,  but  at  a  cost.  As  the  system  generates  more  than  300  messages  per 
hour,  the  subscriber  queue  wait  time  increases  significantly. 

The  OTCIXS  II  protocol  provides  better  performance  for  low  priority  messages. 
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The  servicing  of  high  priority  message  is  comparable  for  both  protocols.  The  data  also 
shows  OTCIXS II DAMA  operations  perform  as  well  as  non-DAMA  operations 
considering  message  throughput  and  utilization,  but  with  higher  wait  and  throughput 
times.  If  the  assumption  is  true  that  DAMA  will  exhibit  fewer  contention  events  resulting 
in  mutual  destruction,  then  DAMA  should  use  the  available  request  opportunities  that  are 
provided.  Frequent  user  polling  tends  to  show  poorer  performance  indicated  by  longer 
queue  wait  times. 


Figure  C3-2.  OTCIXS  I  vs.  OTCIXS II  Minimum  Subscriber  to  Subscriber  Service  Time 
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Figure  C3-4.  OTCEXS  I  vs.  OTCEXS  II  Maximum  Subscriber  to  Subscriber  Service  Time 


#***&• 
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Figure  C3-5.  OTCIXS  II  Minimum:  non-Rescheduled  vs.  Piggy-Back  Queue  Wait  Time 


Figure  C3-6.  OTCIXS II  Minimum:  non-Rescheduled  vs.  Piggy-Back  Service  Time 


Figure  C3-8.  OTCLXS II  Minimum:  non-Rescheduled  vs.  Frequent  User  Service  Time 


Figure  C3-9.  OTCIXS II  Maximum:  non-Res cheduled  vs.  Piggy-Back  Queue  Wait  Time 

V:. 


Figure  C3-10.  OTCIXS II  Maximum:  non-Rescheduled  vs.  Piggy-Back  Service  Time 
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Figure  C3-1 1.  OTCIXS  n  Maximum:  non-Rescheduled  vs.  Frequent  User  Queue  Wait  Time 
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APPENDIX  C  -  SECTION  C4 


OTCIXS  MODEL  NETWORK  DESCRIPTION 


The  following  is  the  source  descriptions  used  to  produce  the  OTCIXS  network 
description  file  (NDF).  This  source  was  converted  to  the  binary  NDF  using  the  OCTEDT 
program  developed  by  Advanced  Digital  Systems  (ADS). 


ISECT 

NETWORK  =  OTCIXS; 

DATE  =  “4  MAY  1999” 

SCENARIO  =1; 

ENDS; 

MSECT 

DEFINE  MESSAGE  =  TTY  A; 

TYPE  =  TTY; 

SELECT  PRECEDENCE  =  (<1:0.8>,  <2:0.2>); 

SELECT  COLLECTIVE  =  (<128:0.18>,  <129:0.17>,  <130:0.17>,  <131:0.16> 

<132:0. 16>,  <133:0. 16>); 

SELECT  NADRPM  =  (<1:0.9>  <2:0.08>,  <3:0.02>); 

SELECT  LENGTH  =  (<  100:0. 10><  500:0.03>,<  550:0.05>,  <  600:0.07>, 

<  650:0.09>,  <  700:0.10>,<  800:9.11>,<  900:0.10>, 

<  1000:0.09>  <  1200:0.06>  <  1400:0.05>,  <  1600:0.04>, 

<  1800:0.02>,  <  2000:0.0 1>,  <  2500:0.01>,  <  3000:0.02>, 

<  4000:0.02>,  <  6000:0.01>,  <  7000:0.01>  <  8000:0.01>); 

ENDDEF; 

DEFINE  MESSAGE  =  TDPA; 

TYPE  =  DATA; 

COPY  TTYAPRECEDENCE; 

COPY  TTYA  COLLECTIVE; 

COPY  TTYANADRPM; 

SELECT  LENGTH  =  (<  100:0.10>,<  500:0.08>  <  600:0.07>,  <  650:0.09> 

<  700:0. 10>,<  800:0. 11>,<  900:9. 10>,<  1000:0.09>, 

<  1200:0.06>,  <  1 400:0. 05>,  <  1600:0.04>,  <  1800:0.02> 

<  2000:0.01>,  <  2500:0.01>,  <  3000:0.01>,  <  4000:0.02>, 

<  6000:0.01>,  <  7000:0.01>,  <  8000:0.01>,  <10000:0.01>); 

ENDDEF; 

ENDS; 

NSECT 

DEFINE  PLATFORM  =  AA01; 
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TYPE  =  SHORE; 

SED  =  1; 

DEFINE  DEVICE  =  TTY; 

CHANNEL  =  (75.0,  7.5, 0.00001, 0); 
ENDDEF; 

DEFINE  DEVICE  =  TDP; 

CHANNEL  =  (4800.0,  8.0,  0.0001,  1); 
ENDDEF; 

DECLAIR  SLCPARAM 

MAXMEM  =  32367; 

PENALTY  =  0.001; 

GUARD  =  (128); 

NOISE  =  BURST  (20.0, 0.03,  8.0, 12.0); 
CLASS  =  TYPE1; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA02; 

TYPE  =  SHIP, 

.  SID  =  2; 

COPY  AAOI.DEVICE.TTY; 

COPY  A00 1  .DEVICE.TDP; 

DECLARE  SLCPARAM; 

MAXMEM  =  32367; 

PENALTY  =  0.002; 

GUARD  =  (129); 

NOISE  =  BURST  (12.0, 0.05,  8.0,  12.0); 
CLASS  =  TYPE2; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA03; 
TYPE  =  SHIP; 

SID  =  3; 

COPY  AAOI.DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM; 
GUARD  =  (130); 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA04; 
TYPE  =  SHIP; 

SID  =  4; 

COPY  AA01.DEVICE.TTY; 
COPY  A001.DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
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GUARD  =  (131); 

NOISE  =  BURST  (10.0,  0.08,  8.0,  12.0); 
CLASS  =  TYPE1; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA05; 

TYPE  =  SHIP; 

SID  =  5; 

COPY  AAO 1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA06; 
TYPE  =  SHIP; 

SID  =  6; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA07; 
TYPE  =  SHIP; 

SID  =  7; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (128); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA08; 
TYPE  =  SHIP; 

SID  =  8; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A001.DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (129); 
PENALTY  =  0.007; 
CLASS  =  TYPE3; 

ENDP; 
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ENDDEF; 


DEFINE  PLATFORM  =  AA09; 

TYPE  =  SHIP; 

SID  =9; 

COPY  AA01. DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (130); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA10; 

TYPE  =  SHIP, 

SID  =  10; 

COPY  AA0 1  .DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (131); 
PENALTY  =  0.001; 
CLASS  =  TYPE3; 

.  ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA11; 
TYPE  =  SHIP; 

SID  =  11; 

COPY  AAOLDEVICE-TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA12; 
TYPE  =  SHIP; 

SID  =  12; 

COPY  AA0 1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 


ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA13; 

TYPE  =  SHIP; 

SID=  13; 

COPY  AA01.DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (128); 
PENALTY  =  0.001; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA14; 

TYPE  -  SHIP; 

SID  =  14; 

COPY  AA01.DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (129); 
PENALTY  =  0.001; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA15; 

TYPE  =  SHIP; 

SID  =  15; 

COPY  AA0 1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (130); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA16; 
TYPE  =  SHIP; 

SID  =  16; 

COPY  AA01. DEVICE.  TTY; 
COPY  A001. DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (131); 
PENALTY  =  0.001; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA17; 
TYPE  =  SHIP; 

SID  =  17; 

COPY  AA01.DEVICE.TTY; 
COPY  AOOLDEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA18; 
TYPE  =  SHIP; 

SID  =18; 

COPY  AA01.DEVICE.TrY; 
COPY  AOOLDEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 
PENALTY  =  0.001; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA19; 
TYPE  =  SHIP; 

SID  =  19; 

COPY  AA01.DEVICE.TTY; 
COPY  AOOLDEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (128); 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA20; 
TYPE  =  SHIP; 

SID  =  20; 

COPY  AA0 1  .DE  VICE.TTY ; 
COPY  AOOLDEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (129); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA21; 
TYPE  =  SHIP, 

SID  =  21; 

COPY  AA0 1  .DEVICE.TTY ; 
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COPY  A001. DEVICE. TOP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (130); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA22; 

TYPE  =  SHIP; 

SID  =  22; 

COPY  AA01.DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (131); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA23; 

TYPE  =  SHIP; 

SID  =  23; 

COPY  AAO 1  .DEVICE.TTY ; 
COPY  A001. DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA24; 

TYPE  =  SHIP; 

SID  =  24; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 
PENTALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA25; 

TYPE  =  SHIP; 

SID  =  25; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (128); 


PENTALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA26; 

TYPE  =  SHIP; 

SID  =  26; 

COPY  AAO 1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (129); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA27; 

TYPE  =  SHIP; 

SID  =  27; 

COPY  AAO I. DEVICE. TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (130); 
PENALTY  =  0.001; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA28; 

TYPE  =  SHIP; 

SID  =  28; 

COPY  AAO  1. DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (131); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA29; 

TYPE  =  SHIP; 

SID  =  29; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA30; 

TYPE  =  SHIP; 

SID  =  30; 

COPY  AAO 1  .DEVICE.TTY ; 
COPY  A00 1  DEVICE.TDP; 
COPY  A002.  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA3 1; 

TYPE  =  SHIP; 

SID  =  31; 

COPY  AA01.DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (128); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA32; 

TYPE  =  SHIP; 

SID  =  32; 

COPY  AAO  1  .DEVICE.TTY; 
COPY  A001  DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =(129); 
PENALTY  =  0.002; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA33; 

TYPE  =  SHIP; 

SID  =  33; 

COPY  AAO  1. DEVICE.TTY; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =(133); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA34; 

TYPE  =  SHIP; 

SID  =  34; 

COPY  AAO  1  .DEVICE.TTY ; 


COPY  A001.DEVICE  TDP; 
COPY  A002 .  SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (131); 
PENALTY  =  0.001; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  -  AA35; 

TYPE  =  SHIP; 

SID  =  35; 

COPY  AAO 1  .DEVICE.TTY ; 
COPY  A00 1.DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA36; 

TYPE  =  SHIP; 

SID  =  36; 

COPY  AAO  1. DEVICE.TTY; 
COPY  A00 1 JDE  VICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (133); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA37; 

TYPE  =  SHIP; 

SED  =  37; 

COPY  AA01.  DEVICE.TTY; 
COPY  A001.DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
GUARD  =  (132); 
PENALTY  =  0.008; 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 


DEFINE  PLATFORM  =  AA38; 

TYPE  =  SHIP; 

SID  =  38; 

COPY  AAO  1  .DEVICE.TTY ; 
COPY  A00 1  .DEVICE.TDP; 
COPY  A002.SLCPARAM; 
DECLARE  SLCPARAM 
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GUARD  =  (131); 

CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA39; 

TYPE  =  SHIP; 

SID  =  39; 

COPY  AA01.DEVICE.TTY; 

COPY  A00 1  .DEVICE.TDP; 

COPY  A002.SLCPARAM; 

DECLARE  SLCPARAM 
GUARD  =  (130); 

NOISE  =  BURST(6.0,  0.8,  5.0, 6.3); 
CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 

DEFINE  PLATFORM  =  AA40; 

TYPE  =  SHIP; 

SID  =  40; 

COPY  AAO 1  .DEVICE.TTY ; 

COPY  A00 1  .DEVICE.TDP; 

COPY  A002.SLCPARAM; 

DECLARE  SLCPARAM 
GUARD  =  (129); 

CLASS  =  TYPE3; 

ENDP; 

ENDDEF; 


ENDS; 

DECLARE  SOURCE 
PLATFORM  =  AA01; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9> ,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.21); 

ENDP; 


DECLARE  SOURCE 
PLATFORM  =  AA01; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08> ,<3:0.02>): 
ARRIVALS  =  POISSON(0.34); 
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ENDP; 


DECLARE  SOURCE 
PLATFORM  =  AA04; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  ,<3:0.02>): 
ARRIVALS  =  POISSON(0.09); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA04; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1 :0.09>  <2:0.08>  <3 :0.02>): 
ARRIVALS  =  POISSON(0.025); 

ENDP, 

DECLARE  SOURCE 
PLATFORM  =  AA02; 

DEVICE  =  TDP, 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.10); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA02; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>, <2:0.08> ,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.01); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA03; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>, <2:0.08>,<3::0.02>); 
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SELECT  NADRPM  =  (<1 :0.09>  <2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.14); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA03; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>, <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,  <2:0.08>,  <3:0.02>): 
ARRIVALS  =  POISSON(0.009); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA05; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.07); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA05; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.009); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA06; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.08); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA06; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 
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SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<I:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.009); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA13; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.20); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA13; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.009); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA14; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.25); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA18; 

DEVICE  =  TTY; 

MSG  =  TTYA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  -  (<I:0.09>,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.025); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA19; 

DEVICE  =  TDP; 
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MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

CT7T  PFT  DT^P'RFTF'  =  ** 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  ,<3:0.02>): 
ARRIVALS  =  POISSON(0.025); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA07; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,  <2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA08; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA09; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA10; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1 :0.09>  <2 :0.08>,<3 :0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
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PLATFORM  =  AA11; 

DEVICE  =  TOP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1 :0.09>,<2:0.08>,<3 :0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA12; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1 :0.09>,<2:0.08>, <3 :0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA15; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1 :0.9>  <2:0.08>  <3 :  :0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>, <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA16; 

DEVICE  =  TDP, 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<  1 :0. 9>,<2:0.08>  <3 :  :0.02>); 
SELECT  NADRPM  =  (<1 :0.09>,<2:0.08>,<3 :0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP, 

DECLARE  SOURCE 
PLATFORM  =  AA17; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1 :0.09>  <2:0.08>,<3 :0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 


202 


DECLARE  SOURCE 
PLATFORM  =  AA20; 

DEVICE  =  TOP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1 :0.9>  <2:0.08>  <3 :  :0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA2 1; 

DEVICE  =  IDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  FOISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA22; 

DEVICE  =  TOP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =*; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>, <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA23; 

DEVICE  =  TOP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>, <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA24; 

DEVICE  =  TOP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>, <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 
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ENDP; 


DECLARE  SOURCE 
PLATFORM  =  AA25; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1 :0. 9>  <2 :0.08>  <3 :  :0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA26; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>, <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<I:0.09>, <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA27; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>, <2:0.08> ,<3:0.02>): 
ARRIVALS  =  FOISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA28; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA29; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<I:0.9>  <2:0.08>  <3::0.02>); 
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SELECT  NADRPM  =  (<1:0.09>  <2:0.08>,  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA30; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  ,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA31; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA32; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<I:0.9>  <2:0.08>;<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA33; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,<2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA34; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 
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SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA35; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA36; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>,  <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>  <3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA37; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9> ,<2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>  ,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA38; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>  <3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA3  9; 

DEVICE  =  TDP; 
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MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08> ,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>  <2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0.003); 

ENDP; 

DECLARE  SOURCE 
PLATFORM  =  AA40; 

DEVICE  =  TDP; 

MSG  =  TDPA; 

USE  DISCRETE  =  0.25; 

SELCET  DISCRETE  =  *; 

SELECT  COLLECTIVE  =  (<1:0.9>  <2:0.08>,<3::0.02>); 
SELECT  NADRPM  =  (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS  =  POISSON(0 .003); 

ENDP; 
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APPENDIX  D 


OTCIXS II  MODEL  SIMULATION  SETUP  FILE  FORMAT 

A.  INTRODUCTION. 

The  OTCIXS  II  simulation  setup  file  is  used  to  specify  run  time  parameters.  The 
network  description  file  (NDF)  specifies  the  network  subscriber  and  traffic  characteristics; 
the  setup  file  identifies  the  environment  characteristic  for  the  subscribers.  These 
characteristic  include  such  items  as  which  NDF  to  use,  non-DAMA  or  DAMA  (including 
the  OTCIXS  II  DAMA  model),  the  net  control  station,  data  block  sizes,  transfer  rates  and 
other  types  of  environment  parameters. 

The  setup  file  format  allows  the  user  to  specify  parameter  data  for  several  exercises. 
This  feature  allows  for  several  variations  of  environmental  characteristics  to  be  run  against 
one  or  more  NDF  definitions.  Thus  analysis  of  various  types  and  methods  of  OTIXS  link 
operations  can  be  performed.  The  following  subsections  describe  the  format  and  contents 
of  the  setup  file. 

B.  GENERAL  FORMAT 

The  setup  file  is  a  text  file  using  standard  ASCII.  Each  record  in  the  file  has  a  one 
character  record  code  identifier  as  its  first  non-blank  character.  The  record  code  is 
followed  by  one  or  more  blanks  and  then  auxiliary  information  related  to  the  record  code. 
The  general  format  of  the  setup  file  record  is  as  follows: 

C  PARAM  DATA 

Where: 


209 


c 


-  Record  Code 


PARAM  -  Parameter  identifier  (if  any) 

DATA  -  Data  (if  any) 


C.  RECORD  CODES 

The  following  is  a  list  of  the  record  codes  in  the  setup  file. 


RECORD  CODE 

A 

C 

D 

E 


F 


I 

M 

N 

P 


Q 

R 


DESCRIPTION 

Enables  OTCIXS II  model.  This  code  must  be  included  in  each 
exercise  that  runs  an  OTCIXS II  model. 

Specifies  the  Crypto  synchronization  up  link  and  down  link  factors 
Enables  DAMA  model  and  DAMA  bit  error  rates.  This  model  runs 
the  non-DAMA  OTCIXS  model  using  a  DAMA  transmit/receive 
device  simulation.  This  model  is  different  from  the  OTCIXS  II 
model:  the  OTCIXS  II  model  is  a  network  protocol  designed 
specifically  to  operate  in  a  DAMA  environment. 

Specifies  the  name  of  the  even  history  file.  This  record  is  required 
Specifies  subscriber  to  satellite  DAMA  signal  strength  (figure  of 
merit  (FOM))  characteristics  based  on  three  class  types  of 
subscribers  such  that  type  1  subscribers  have  very  good  signal 
quality,  type  2  subscribers  have  fair  signal  quality,  and  type  3 
subscribers  have  poor  quality  signals.  The  subscriber  with  the  best 
FOM  value  will  override  other  subscribers  when  a  transmit 
contention  condition  occurs. 

Specifies  the  name  of  the  NDF.  This  record  is  required. 

This  record  specifies  a  traffic  multiplier  that  is  applied  to  all  traffic 
sources.  This  value  is  multiplied  to  the  rate  factor  in  the  NDF  that 
specifies  subscriber  message  traffic. 

Title  of  the  current  simulation. 

Specifies  signal  to  noise  values.  Only  one  pair  can  be  specified  per 
record,  and  at  least  one  record  must  be  specified.  However,  these 
values  only  need  to  be  defined  once,  and  will  be  used  by  all 
succeeding  exercises.  If  these  values  are  not  defined,  those 
equations  that  use  signal/noise  values  to  compute  transmission 
errors  will  produce  erroneous  results. 

Specifies  link  environment  parameters  such  as  net  control  station, 
subscriber  link  data  rate,  etc. 

Specifies  four  values  to  be  used  as  initial  (seed)  values  for 
computing  random  numbers.  These  values  must  be  specified  at 
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least  the  first  time  the  simulation  is  run. 

S  Specified  the  scenario  identifier  and  exercise  identifier. 

T  Specifies  the  termination  criteria  for  this  exercise. 

X  Specifies  the  name  of  the  summary  file.  This  record  is  required. 

The  slash  (/)  character  specifies  the  end  of  the  parameters  for  a 
given  exercise.  Any  parameters  that  follow  will  be  used  for  the 
next  exercise.  This  process  continues  until  the  end  of  setup  file 
condition  occurs.  An  end  of  file  condition  will  terminate  the 
simulation;  thus,  the  last  exercise  should  end  with  the  slash 
character  followed  by  the  end  of  file. 


D.  SPECIFIC  RECORD  CODE  FORMATS 

a.  OTCTXS II  Enable 
A 

Note:  the  A  stands  for  SATLINK-A;  this  is  a  carry  over  from  the  original  program  that 
referred  to  a  new  experimental  protocol  as  SATLINK-A.  This  experimental  protocol  was 
incorporated  into  the  OTCIXS II  protocol. 

b.  Crypto  Synchronization  Factors 
C  dnlf  uplf  dnlf  uplf  dnlf  uplf 

Where: 

dnlf  -  Real  number  specifying  the  down  link  performance, 
uplf  -  Real  number  specifying  the  up  link  performance. 

c.  DAMA  Mode 

D  berlb  berub  berlb  berup  berlb  berub 

Where: 

berlb  -  Bit  error  rate  lower  bound, 
berup  -  Bit  error  rate  upper  bound. 
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d.  Event  History  File 

E  filespec 

Where: 

filespec  -  file  specification  (30  characters  or  less)  in  the  form 
device:  [directory]filename.extersnion;revision  .  The  device  and  directory  default  to  the 
current  user  area.  The  cycle  defaults  to  the  most  recent. 

e.  DAMA  Figure  Of  Merit 

F  fomlb  fomub  fomlb  fomub  fomlb  fomub 

Where: 

fomlb  -  figure  of  merit  lower  bound.  The  value  should  be  a  real  number  between  0 
and  1  The  three  pairs  of  numbers  are  used  for  the  three  different  type  class  of  subscriber 
transmit  signal  quality. 

fomup  -  figure  of  merit  upper  bound. 
f  Network  Description  File 
I  filespec 

Where: 

filespec-  file  specification  (30  characters  of  less)  in  the  form 
device:  [directory]filename.execution;revision.  The  device  and  directory  default. toi  the 
current  user  area.  The  cycle  defaults  to  the  most  recent.  This  file  name  must  be  the  output 
file  from  the  OTCEDT  program. 
g.  Traffic  Multiplier 
M  number 

Where: 
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number-  Real  number  used  to  change  the  subscriber  transmission  rates.  Default  is  1. 
h.  Simulation  Title 


N  title 


Where: 


Title  -  1  to  60  ASCn  characters 
i  Signal/Noise  Specification 
P  snr  per 


Where: 


snr  -  Signal  noise  ration;  this  value  should  be  between  the  low  signal  noise  and  high 
signal  noise  values,  inclusive,  used  in  the  NDF  model  definition  (NOISE  =  BURST 
(initiation  time,  average  duration,  low  signal  noise,  high  signal  noise)). 

per  -  Signal  error  rate  probability;  the  grater  this  value,  the  greater  the  probability 


of  noise  burst  errors  occuring. 


j.  Link  Environmental  Parameters 


ADRSIZ 

integer 

ADVUSR 

integer 

BLKSIZ 

integer 

CHKSUM 

integer 

CRYPTO 

00 

GDTSIZ 

real 

HPRRS 

integer 

LBPS 

real 

LRATE 

real 

MAXADR 

integer 

MAXCPY 

integer 

MSGCHK 

integer 

MSGHDR 

integer 

MSGHP 

integer 

NCSID 

sid 

PTRBYT 

integer 

PTRCHK 

integer 

RCVMDO 

{T.F} 
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RRSGDT 

real 

RESCHD 

TOTRRS 

integer 

TTYMAX 

integer 

Where: 

ADRSIZ  -  Length  in  bytes  per  datalink  message  address.  Range  of  values:  1  to  4. 
Default :  2. 

ADVUSR-  Specifies  frequent  users  polling  list.  The  numbers  must  correspond  to 
the  subscriber  identification  numbers  used  in  the  NDF  definitions.  The  subscribers  in  the 
polling  list  are  automatically  acknowledged/polled  for  low  priority  data  transmissions. 
Range  of  values:  1  to  number  of  subscribers.  Default :  None 

BLKSIZ  -  Number  of  bytes  per  data  block.  Range  of  values:  64  to  1024.  Default : 

256. 

CHKSUM  -  Number  of  bytes  per  each  data  block’s  checksum.  Range  of  values:  0 
to  4.  Default :  2. 

CRYPTO  -  Crypto  device  type  of  KG-84.  Range  of  value:  84.  Default :  84 
GDTSLZ  -  Guard  time  in  seconds.  Range  of  values:  0.0  to  1.0.  Default :  0.25. 
HPRRS  -  Specifies  the  number  of  high  priority  reservation  request  slots.  Range  of 
values:  1  to  20.  Default :  1. 

LBPC  -  Number  bits/character  transferred.  Range  of  values:  6.0  to  10.5.  Default : 

8.0 

LRATE  -  Subscriber  satellite  transfer  rate  in  bits/second.  Range  of  values:  75.0  to 
19200.0.  Default :  2400.0. 

MAXADDR  -  Maximum  number  of  addresses  per  message.  Ignored  by  simulator. 
Range  of  values:  0  to  8.  Default :  5. 
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MAXCPY  -  Number  of  times  a  subscriber  uplinks  transmission  units  (TU)  will  be 
transmitted  in  a  SATS  or  BUSY  cycle.  A  value  of  zero  activates  dynamic  computation  of 
the  number  of  transmits  based  on  the  subscriber  class  type  defined  in  the  NDF  (type  1  is 
best  quality  transmission  and  type  3  is  poorest  quality).  Range  of  values:  0  to  5.  Default:  2. 

MSGCHK  -  Length  in  bytes  of  datalink  message  checksum.  Range  of  values:  0  to 
4.  Default :  2. 

MSGHDR  -  Length  of  datalink  message  header.  Ignored  by  simulator.  Range  of 
values:  0  to  16.  Default :  0  (included  in  data  length). 

MSGPH  -  Number  of  messages  per  hour  to  be  generated  in  the  network  by  all 
subscribers.  Range  of  values:  10  to  1000.  Default:  140. 

NCSID  -  Net  control  station  identifier.  Must  be  one  of  the  subscribers  identifiers 
assigned  in  the  NDF.  Range  of  values:  1  to  total  number  of  subscribers.  Assumes 
subscribers  are  assigned  sequential  numbers  starting  with  1 .  Default :  1 . 

PTRBYT  -  Number  of  bytes  per  datalink  TU  message  pointer.  Range  of  values:  0 
to  4.  Default:  2. 

PTRCHK  -  Number  of  bytes  per  datalink  TU  pointer  block  checksum.  Range  of 
values:  0  to  4.  Default:  2. 

RCVMOD  -  Message  processing  takes  place  after  every  copy  (TRUE)  or  after  last 
copy  (FALSE).  Range  of  values:  TRUE,  FALSE.  Default:  FALSE. 

RESCHD  -  Enables  automatic  “piggy-backing”  of  link  access  during  transmission 
unit  processing.  The  default  state  is  no  piggy-backed  rescheduling;  this  option  turns  it  on. 
Range  of  values:  None.  Default:  False  condition. 

RRSGDT  -  Reservation  request  slot  guard  time.  Valid  for  non-DAMA  link 
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operations.  Range  of  values:  0.0  to  1.3.  Default:  0.5. 

TOTRRS  -  Total  number  of  reservation  request  slots.  Range  of  values:  3  to  20. 
Default:  8. 

TTYMAX  -  Maximum  length  of  TTY  messages,  in  bytes.  Range  of  values:  1024 
to  8192.  Default:  8000. 

Note:  These  parameters  persist  from  one  exercise  to  the  next  and  need  only  be  entered 
when  they  change  from  the  default  or  the  last  entered  value. 
k.  Random  Number  Seed 
R  integer  integer  integer  integer 

Where: 

integer  -  Number  used  as  initial  value  for  random  number  generation. 

L  Scenario  Exercise  Specification 
S  scenario  exercise 

Where: 

scenario  -  Integer  identifying  the  scenario 

exercise  -  Integer  identifying  the  exercise  in  the  current  scenario 

m.  Termination  Criteria 

T  ttymsg  datamsg  maxtime 

Where: 

ttymsg  -  Integer  indicating  maximum  number  of  TTY  messages  to  be  sent. 
Default:  10. 

datamsg  -  Integer  indicating  maximum  number  of  datalink  messages  to  be  sent. 
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Default:  50. 


maxtime  -  Real  number  indicating  maximum  simulation  time.  Not  clock  time  or 
computer  time,  but  simulated  clock  time.  Time  interval  is  entered  in  seconds.  Default: 
1200.0 

n.  Summary  File 
X  filespec 

Where: 

filespec  -  file  specification  (30  characters  or  less)  in  the  form, 
device:  [directory]filename.extension;revision.  The  device  and  directory  default  to  the 
current  user  area.  The  cycle  defaults  to  the  most  recent. 
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APPENDIX  E 


SETUP  FILE  STANDARD  VALUES 

A.  NON-DAMA  PARAMETERS 

otcixs  n 

I  MODELl.NDF 

R  127  73  149  29 

C  0.9787  0.9787  0.9587  0.9587  0.9344  0.9344 
F  0.7  1.0  0.5  0.8  0.3  0.6 

P  8.00  0.0000145 

P  8.45  0.000015 

P  8.90  0.0000155 

P  9.35  0.000016 

P  9.80  0.0000165 

P  10.25  0.000017 

P  10.70  0.0000175 

P  11.15  0.000018 

P  11.60  0.0000185 

P  12.00  0.000019 

Q  LBPC  8.0 

Q  IRATE  2400.0 

Q  NCSID  4 

T  100  1000  18000 

B.  DAMA  PARAMETERS 

N  OTCIXS  n 

A 

D  0.000015  0.00002  0.000005  0.00001  0.0000015  0.000004 
I  MODELl.NDF 

R  127  73  149  29 

C  0.9787  0.9787  0.9587  0.9587  0.9344  0.9344 
F  0.7  1.0  0.5  0.8  0.3  0.6 


p 

8.00 

0.0000145 

p 

8.45 

0.000015 

p 

8.90 

0.0000155 

p 

9.35 

0.000016 

p 

9.80 

0.0000165 

p 

10.25 

0.000017 

p 

10.70 

0.0000175 

p 

11.15 

0.000018 

p 

11.60 

0.0000185 
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P  12.00  0.000019 

Q  LBPC  8.0 

Q  LRATE  2400.0 
Q  NCSDD  4 

T  100  1000  18000 
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